This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I will develop a web app that must use states, like login status, user data, former requests parameters, etc.
For that, I'm planning to implement View-to-Controller Broker, so that Controller has a Broker that offers all operations that Servlets can consume. This Broker object will also have these data in it. When a user logs in, a Session is created, this object is instantiated and set in the Session as an attribute.
My concern is about memory leak. I fear a user leaving and his session remaining, and its attributes hold RAM resources. I could decrease session expiration time, but then user would need to login too often.
Also, if it gets a lot of visits, I may use some pool pattern to managed reusable Brokers, instead of letting them be destroyed and construct new ones.
How can that be done with Servlet Sessions? How can I see a user has gone for like 10 minutes and take Broker out of his session, without destroying the session and forcing a new login? And how do I know a session expired and its Broker is available to be cleared and reused?
Hikari Shidou wrote:I could decrease session expiration time, but then user would need to login too often.
You do realize that the session timeout only applies after a period of inactivity, right? The session will never time out while a user is actively using the site.
Joined: Jan 22, 2013
Let's say 10K users will use the software during a month, with 1K logging at least once a day, with a maximum concurrent use of 150 users online.
My concern is that, for exemple, a session lives inside application for a week, with the object in it, resulting in 4K living sessions. Instead of having 4K objects in memory, I could have a pool of 200 objects.
But thinking better, these objects won't have so much data in them, and a normal session resource must use more RAM then them.
Also, if I take the object from a living session, when it comes back in use I won't have user data anymore, so he will need to be authenticated again.
Ok... let's hope this optimization not be needed at all and let Tomcat and garbage collector handle dead objects and just construct new ones.