• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

HttpSession

 
Paul Wetzel
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
is there any reason that the HttpSession is not something that one would really want to use. In my days as an ASP programmer we avoided using/storing anything in the session object. I cannot remember why (maybe i dont want to remember anything related to asp) but i know it was a bad idea/last result. thanks in advance
paul
 
Paul Wetzel
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
here is why we didn't want to use the session object in ASP:
1)
waste memory because they live for ___ minutes past their last use.
2)
waste threads if you put any objects (made with server.createobject) in a session variable.
3)
limit the code to users accepting cookies which may mean someone who disables cookies may not use that script at all.
It seems as though point 3 is valid for servlets, any other thoughts?
thanks again
pjw
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, I'll try and answer your points in order.
1) waste memory because they live for ___ minutes past their last use.
This is one of the peculiarities of trying to impose a concept of state onto a stateless protocol like HTTP. A server can't ever really know that another connect for a session isn't going to arrive, so you have to have at least a timeout system to end the session.
In practice, there are ways to avoid this. If you have a defined sequence to the transactions in your session, your servlet can explicitly end the session when the last transaction is processed. This will free up resources. If you just leave it, it will be subject to a timeout, though.
The trick is to put only stuff in the session that really needs to be there. If you have a fast database available, for instance, you can just store a lookup key in the session, and everything else can live in the database.
Even a Hashtable in the web context can do that job.
2) waste threads if you put any objects (made with server.createobject) in a session variable.
I think this must be ASP specific. Most Java servlet engines have sensible thread management, and don't spin off a new thread for each object. Because sessions are potentially shared between multiple connection threads, they are usually singletons, in the servlet engine context.
3) limit the code to users accepting cookies which may mean someone who disables cookies may not use that script at all.
You're right in that the simplest way to do session management is through cookies. But it's not the only way. The servlet API has an explicit mechanism for encoding session information in URLs sent to the client. It means an extra method call for each URL that you send back to the client, but it does work with all browsers.
In my opinion, the way to build a servlet-based web site or web application is to do as much as you can statelessly, but don't shy away from using sessions if you need them. They are a very powerful technology.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic