Yes I talk about clustering but not especially failover, because that is when one system fails and another system takes over. We use clustering to release the burden of the different application servers a little bit and the loadbalancer decides that the request is going to the application server that is not very busy at that moment.
What I mean is:
The request of the client can go to another application server depending on what the loadbalancer (lb) decides what is best at that moment in a clustered environment.
Suppose that the lb decides to send the request this time to another application server (with another jvm of course) than last time. He has to transfer the HTTP-session of the servlet container. But what happens now with the static variable that I had declared in some code that was called from the first request? A static variable is a class variable which is bound to a jvm. Is the static variable also transfered? I once read that that definitely does not happen, but some people say it does. For us this is a production situation and I cannot emulate the situation because we are only loadbalancing in production-situation.
I don�t think the static variable would be transferred. Or can�t think how that could possibly happen. So if I understand you correctly, your question is now about replication of data in your cluster. Two things here - 1) Check if your application server provides session data replication as part of their clustering support. 2) If you require the data stored in static variables elsewhere in your code transferred then that data needs to be part of the session so that the container can help you with replication.
If you think from a container point of view I am not sure how the container can possibly know which application data needs to be replicated outside your session (for example). I don't know what application server you are using. However, weblogic does something like this - Data in web tier that you want to be replicated should be bound to the httpsession. Weblogic has hooks that listen when an attribute is bound or modified (session.setAttribute etc). When such events occur weblogic understands which session attributes changed/bound and then replicates the entire object graph associated only for the delta in httpsession. Therefore, one consequence of this is, if you have an object that was already bound to the session in your previous request and you made changes to that object in subsequent request then you need to explicity invoke the setAttribute() in your code. Doing so will fire the weblogic listeners attached to this event and weblogic will understand that the object graph associated with the associated session attribute needs to be replicated. This replication happens to a secondary server before the response is served at the end of http request. Otherwise, I am not sure how application servers can figure out what are the objects that requires replication unless we communicate that somehow. [ October 24, 2005: Message edited by: Sathvathsan Sampath ]
He has to transfer the HTTP-session of the servlet container.
Our container doesn't do that ... does yours? We persist the session to the database so if a user comes to a different server and there is no session in memory the container gets it from the database. There is definitely overhead to this, but it's worth the price to let the user bounce from one server to another with no session data loss.
Static variables live within the JVM. I wouldn't expect any container to attempt to synchronize them across a cluster. Google for "distributed java cache" and see some solutions for state synchronization. Tangosol is a strong commercial solution.
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
What container are you using that doesn't support session migration? I know it isn't a requirement in the specs, but most of the commericial containers I have worked with do.
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook