Question

I have a web app deployed to three servers running Apache, Tomcat and a load balancer in front of them. Now I am thinking of clustering them.

Here are the options usual options and my constraints that I am aware of:

1. Serialization based Session clustering:
   In my case, the application uses a lot of objects in session. So I would prefer not to go with this solution. Also the no of servers is likely increase to more then five in the near future.

2. Terracotta:
   Sounds interesting but buying an enterprise license is not an option.

3. Make the application stateless:
   Sounds tempting although it is a bit of a work. I would love to hear some design guidelines and experiences on it.

Any other advices?

My primary goal is Failover.

Answer 1

Traditionally, it’s a rare web-app that is truly stateless, though I guess in these Ajax days keeping the state in the Browser is more common.

If your intent is to use clustering so that the individual users sessions survive the loss of a server then you are going to need to pay some kind of transfer cost. You might:

• Keep everything in a database. Maybe serialised as a blob. You need to housekeep those blobs when sessions timeout. App servers such as WebSphere have that capability.
• Use some kind of memory-memory replication. Again there’s going to have to be some transgfer/serialisation cost. You can trade off the frequency of that replication against the potential for loss of recent updates to the session.

In either case you aim for “session affinity”: the user’s requests default to going to the same cluster member, effectivly their “home” instance acts as a write-though cache.

I don’t know what’s provided off-the-shelf in your environment, ideally your server provider should have session management facilities built in – writing this stuff your self is not completely trivial.