wood burning stoves 2.0
The moose likes Tomcat and the fly likes Session affinity with no replicaiton Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Session affinity with no replicaiton" Watch "Session affinity with no replicaiton" New topic

Session affinity with no replicaiton

Adam Zimowski

Joined: Sep 12, 2005
Posts: 2

I'm building a custom session failover solution on top of an existing system that persists state to HttpSession and uses session replication. In the new schema session state will be saved to a database, by serializing attributes (only when they're new or changed) using HttpSessionAttributeListener and HttpSessionListener (for new sessions). Therefore the new system will be using HttpSession only as a "cache" where true state will be stored at the db level. Session affinity and load balancing will be in place, but session replication will be turned off since it's not necessary. When server "A" fails, the next request posted to server "B" will cause server "B" to de-serialize all attributes from the database into a newly created HttpSession.

My question is:
Based on the above background, say you have a cluster of two tomcat servers (A and B) with session affinity turned on, but no session replication. Say session 1 was established at server "A", which after some time fails over. Now "B" gets a request that should have gone to "A". Will "B" get a session with same session id that "A" was getting prior to failover? Will the session be invalid? Will the session be empty? I'd think "B" will get an empty, invalid session with the same session id as "A" was getting prior to fail over since request from the client (browser) still has the cookie. I'm just not 100% certain... My new design assumes that same session ID comes to "B" so that attributes can be deserialized from the database using session ID as the primary key.
Ulf Dittmer

Joined: Mar 22, 2005
Posts: 42965
I'd advise to go all the way in your custom session handling. That means not using the Tomcat session handling at ell, but using your own by creating and reading the relevant cookies yourself. It's not that much work, and that way you get to decide yourself if a session ID is valid or not (which, in your DB-backed case, it should always be).
Adam Zimowski

Joined: Sep 12, 2005
Posts: 2
Thanks for your suggestion - it's a good one but can't use it. The application is too large with HttpSession.settAttributes all over the place, and I'm on too small of a budget with this project. I would go all the way if I were designing something from scratch though. Anyway, my question is still unanswered. I will be conducting a simulation experiment of sort, and post back the results. Since I only have one server, I will start tomcat as usual and navigate to a few pages, outputting session id, isNew, isValid, etc. Then,, brute force: "killall java" (this is linux environment), but keep the browser window open (as if the user was idle on the site). Then, start Tomcat again, go back to a browser window and navigate again. Not sure if this is a good test, but if anyone knowledgable in this matter could agree it's a valid test (or not) please let me know. Also, if anyobody simply knows for sure the answer to my original question, please let me know as well.

I agree. Here's the link: http://aspose.com/file-tools
subject: Session affinity with no replicaiton
It's not a secret anymore!