WE have developed an application (involves JSP , servlets) to be deployed on single set up senvironment.
One important thing is we also do use HttpSession.
Now are application is going to be deployed in a clustered environment.
What are the things we need to take care so as to ensure the smooth functioning of the app even in a clustered environment
Please do post any info regardign the same
Weblogic should have extensive documentation on using a clustered environment, look it up if you havent already, there could be some weblogic specific issues that you need to be aware of.
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?
I'd expect other J2EE vendors to do something similar to be competitive. Or is this in the spec?
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.