Originally posted by Sonny Gill: make sure of is that any objects that are set as an attribute on the ServletContext or HttpSession implement Serializable, so they can be replicated across the cluster.
Any idea how an application server implements this? say i store an Integer in httpsession, then there is no way this object can change (immutable). So i can serialize the session information at the point when somebody does a setAttribute and i s'd be ok when there is a fail over.
Now if i store a ArrayList in session, the list 'might' get serialized when i store the list in the session (i mean when i do a setAttribute). later if i change the list, how does the app server realize that the session object has changed and hence needs to be serialized in some form so that other servers in the cluster can pick it up?
Does somebody have any idea as to how it is done generally?
WebSphere has an option to write your session to a database. There are a few options in how to trigger a write ... I think any access, any change, time interfaval but I defer to configuration experts to get that bit right.
I'd expect other J2EE vendors to do something similar to be competitive. Or is this in the spec?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Mar 06, 2001
Originally posted by Stan James: There are a few options in how to trigger a write ... I think any access, any change, time interfaval
thanks. Yes i was curious about the 'when' part esp wrt mutable objects. Replicating after a definite time interval is definitely an option.
So 'store mutable objects back into the session when changed'
- would this qualify as a best practice esp if we want things to work perfectly in a clustered enviroment, ofcourse assuming that the vendor's implementation of setAttribute uses that as a trigger. I cant think of any other way by which the container could figure that mutable object has changed unless we tell it explicitly.
Joined: Jan 29, 2003
Best practice ... well, it's a necessary one some times. We're asking WebSphere to save the session to the database. It's critical for us that if the load balancer has some reason to move users to another server then users do not lose any session data. There is some performance cost and we had a heck of a time getting the right versions of WebSphere, the vendor framework and UDB to make it actually work. It might be a better practice to not have any session data, but we've already gone beyond that. Now we just try to keep session data small.