Link to home
Start Free TrialLog in
Avatar of willa666
willa666Flag for United States of America

asked on

HttpSession serialization

What triggers Weblogic to serialize the session? We are having an issue where an instance of an object that is put in session is not available when session state is restored via deserialization because the class des not implement the Serializable interface. We are going to modify the class to implement Serializable, however, it is unclear to us why the app server is deciding to store session state to disk.

Note that we have been deploying the application to a specific node of a clustered weblogic install for a while, but did not start to see this issue until today.
Avatar of mbvvsatish
Flag of Canada image

good article on "Session Management for Clustered Applications"

this will provide the answer for you
Avatar of Ajar

WebLogic Serializes the session objects during replicating them on other servers in a cluster.  The objects that you put in session should be serializable along with all the fields in them. If certain fields are not serializable, e.g Output Stream, Socket etc then declare that field as transiet.  

Avatar of Ajar

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Everything you put into an http session (and everything Weblogic may put into the session on the back end) will automatically (attempted to) be serialized by the appserver when appserver participates in a cluster.

So very simply, the answer to your question "What triggers Weblogic to serialize the session?" is the Servlet specification.  That specification states what appservers can and cannot to do be J2EE compliant.  With regard to sessions, the appservers must attempt to serialize all data stored in the session.  You can choose the *storage* methodology (be it in memory, database, disk, etc..) but the appserver does the actual serialization.  I believe the default storage for Weblogic is in memory, so really it's trying to store those objects in the appserver cache.  It can store non-serializable objects in its in-memory cache, but if that server fails those objects weren't passed to other members of the cluster so you will lose them.

That's why it's critical to ensure all your session objects can be serialized.   Ajar's code will help you to test session-stored objects.