Menu
Let's say we have a web application backed by a servlet engine/container like Tomcat. A user logs in. The database record for that user (represented by an instance of class User, let's say) is loaded, and we can store this as a session attribute with the key "currentUser", set it once, and use it to handle subsequent requests. In addition, we put more objects in the session attribute. Pretty basic stuff.
Now, if we need to deploy some new code and reboot Tomcat... The user sessions are still intact after reboot (restored from disk/db) as long as we don't change any of the classes whose instances are stored in the user session. But this is a big problem. I don't want users losing their sessions on new code release.
To get around this problem, I suppose that I can store in the session object only instances of classes that are assumed to not ever change (like storing the logged-in user's ID as an Integer as opposed to an instance of the User class). Then I'd never run into a problem of not being able to deserialize the session object upon reboot. But this makes things slightly more complicated as now I have to use the ID to load the actual object from the database, etc (and with caching, performance hit is not really an issue).
Is this what's typically done to get around this issue?
699
By default, the Tomcat instance is configured to store all sessions and their data in memory. Under certain circumstances it may be appropriate to persist the sessions and their data to a repository.
In session management, Tomcat creates a session id whenever client's first request gets to the server (However, other servlet containers may behave differently). Then it inserts this session id into a cookie with a name JSESSIONID and sends along with the response.
To find out the number of active sessions, you can use Tomcat's internal statistics that can be accessed using JMX (Java Management Extension). You can also use a JavaEE applications monitoring tool, such as JavaMelody, which helps you monitor Java or Java EE applications in QA and production environments.
Simple Solution
as you suggested, load only the userId in your session, and use cache service such as ehcache to retrieve user objects. If the user object does not exist, it will be loaded the first time but then it will be cached and subsequent requests will pretty fast. If you are concerned about your user class changes, make your cache memory based only so it will reset between server reboots.
Platform solution
Take a look at Terracotta (http://www.terracotta.org/). If you are able to deploy your sessions on their platform, they will allow you to maintain them between server reboots as well as update the actual user class while keeping old fields. Pretty cool things once you have it up and running.
Keep in mind though that Terracotta integration is not simple and not for novices. The benefits however are scalability and high availability that all web applications require in general.
148
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
