I know that it may be a dumb question, but is there any other way to obtain a Session object besides calling:
HttpSession session = req.getSession();
The reason I am asking is because, the Session object doesn't "travel" across the network but instead it lives on the server, so then why in order to obtain it you need to ask the object from HttpRequest class that comes from the client to give it to you?
And, does anybody know, is there any limitation on the number of Session objects that you can maintain on the server at any given time, is there a memory issue, or different OS's handle this differently.
Actually you are asking a good question!.
True, the session object lives on the server, but HTTP is stateless. Therefore, a sessionID (typically in the form of cookie) is exchanged between the client and server. That is why you have to get the session from the request object. Once the sessionID is known the server can retrieve the correct session object that is associated with the request.
I typically tend to use the following in the servlets that I write:
HttpSession session = request.getSession(true);
This either creates a session or retrieves an unexpired one.
I dont know of any fixed limits on the number of sessions that a server can support. Obviously, you can run out of memory if too many(large) objects are stored in the session. I'd just be careful of what is stored in the session.
Hope that helps.
thank you for your responce. I was aware of the details you provided and that's the reason why I asked the question.
so, I was wondering why after creating the Session object on the server with getSession(true) you need to go back to the HttpServletRequest that comes from the client and obtain it. Well, the Session object has to be associated with cookies on the client, but shouldn't be there another way to get the Session object ( after it was created on the Server ) by asking the Servlet Container for example. Just food for thought...
Well, how about if the user deleted the cookies from his box, so you will need to recreate the Session object again. Well, there should be a different way of maintaining the client-webserver persistence w/o this being dependent upon cookies on the client.
You can use a URL/querystring parameter to manage state without using cookies - the SessionID is stored in this parameter instead of the cookie, and managed by the Servlet container in just the same way. I am under the impression that there are ways of doing this automatically from within a servlet.
I am not aware of another way to get at the Session object.
It is my belief that we are using technology to solve problems that the underlying infrastructure (HTML/HTTP) was not designed for. FTP is stateful, HTTP isnt -- go figure!. Therein lies the fundamental problem. It is actually quite incredible how far we have come in terms of being able solve some of the nasty headaches that surround the statelessness issue. There must be a better way to do this -- I am sure new approaches and technologies will emerge soon. Enough of my rambling...
You've asked some good questions - questions that in a way relate back to the fundamental protocols. If I could ask Tim Berners Lee one question it would be: "Did he really intend the World Wide Web to be used the way it is used today?".
Sorry about the digression and turning this into a philosophical discussion.
this pretty much makes it clear...everything is blury ..still!
For what its worth, check out the following article about PseudoSessions. As it is written, I have some concerns about performance (IO bound?). However, since the source is provided, one can always improve on it if it is of relevance.
thank you! this article is good. Exactly what I was looking for. again, another proof that the spec doesn't always cover the real - life need and you need to come up with a smarter solution.
Glad to have provided a pointer that you find useful and I agree with your comment as well. The author of article suggests using the file system as a persistant store. Wouldn't there be performance and resource contention (read/write locks?) issues around that?. In principle, I like what is suggested by the author. Perhaps using a RDMS for persistance would make that approach more robust and scalable?. In some regards, WebSphere and other vendors offer session persistance via RDMS. What they do not provide is the concept of PseudoSessions (which is what you were after I guess).
I'm interested in knowing how the proposed approach actually works out as in a case like yours. Would greatly appreciate any feedback you can provide either back here in this forum or via email (rrajen at mediaone dot net)