This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
We are using servlet's HttpSession in our application. Just because of some of the drawbacks of HttpSession, I am looking for an alternative to HttpSession. Has anyone used/experienced pseudo session previously or has replaced HttpSession with any other alternative? Pseudo session is an efficient mechanisam especailly very scalable across multiple servers but I am seeking, if anyone has any experience to share.
Also, as a side note: In current application we have two browser windows (parent and child). Parent and child window both are completely different applications. Appication A invokes app. B as child window. Whenever user closes child window (by any means ALT+F4 or clicking browser "x" button) I need to clear the session of application B (child window). Currently I am working on dirty solution for this but does anyone have any better idea on doing this?
Sounds like a maintanence nightmare having the dual window apps. But if the child window (app B) is closed and it is separate from app A, then closing the child will kill the child's session automatically (as you say you want to happen). Did you really mean that closing A would kill B's session or that closing B would kill A's session?
What are the drawbacks of HttpSession that you are dealing with? I've had pretty good luck wrapping HttpSession from a filter.
What drawbacks of HttpSession are you referring to? Session management in JEE webapps is meant to be handled via the Servlet API and HttpSession, so I'd be curious as to why someone might feel the need to do otherwise.
Joined: Dec 16, 2004
Joined: Dec 16, 2004
Jason: Disadvantages of using session. 1)Session objects are stored in memory and consume significant resources. 2)Session tracking relies on cookies. Some users turn off cookies for various reasons, especially for security reasons. 3)Session tracking uses session identifiers that are created by the server. 4)In situations where many Web servers and many JVMs are used, the session tracking simply does not work because servers do not always understand each other's session identifiers
Joined: Nov 09, 2000
This should handle your problem with unLoad...
Had some trouble getting this to post due to UBB filters, so replace "Lood" in onLood and onUnlood with "Load", and replace "onClack" with "onClick". :roll: [ August 17, 2005: Message edited by: Jason Menard ]
Originally posted by Vicky Pandya: Jason: Disadvantages of using session. 1)Session objects are stored in memory and consume significant resources. 2)Session tracking relies on cookies. Some users turn off cookies for various reasons, especially for security reasons. 3)Session tracking uses session identifiers that are created by the server. 4)In situations where many Web servers and many JVMs are used, the session tracking simply does not work because servers do not always understand each other's session identifiers
I think you may be a bit too concerned with sessions taking up too much room in memory. Too many times someone reads an article that gives them the idea that sessions are evil and that is far from the truth. There are very few applications that would have better performance without sessions.
If it is an internal app, the number of users should not be all that many and so the session space is minimal. Also, an internal app can require cookies.
If it is an external app, much can still be done to manage session data properly without throwing the concept of sessions completely out the window. Also, URL rewriting can easily take the place of cookies to maintain session support.
Some data will have to be stored somewhere. If it is not in session, you will need to propagate it from page to page, which uses more bandwidth because that data has to be sent client-server/server-client with every request. You should try to find the right balance between bandwidth and memory to have optimal performance and maintainability.