Share Sessions between tomcat instances (without u

Question

I'm going to have 3 Tomcat servers and a Load Balancer that dispatches the requests without using 'sticky sessions'.

I want to share sessions' data between the servers and I'm thinking in persisting them in DB. I'd like to use memcached as a layer in front of my DB to serve the requests faster and to don't put my db under heavy load.

I'm thinking in providing my customized tomcat Manager that uses memcached before getting/persisting session data to DB as at the moment I don't see a transparent way of doing it (it means that I'll have to manage it again in the case I switch to another app server).

Is this a good solution or do you see a better approach?

Answer 1

I think Terracotta Web Sessions is what you want.

Answer 2

We do a similar thing in our application (Weblogic, but that doesn't matter), where we have a unique session key stored as a cookie in the browser. That key will then be used at each request to restore the relevant session data from the database.

Using this principle, we can always switch over to another server using the load balancer without the user noticing anything. In addition to that, we hardly store anything relevant in the user's session and work with a lot of hidden fields in the browser (the load balancer supports URL encryption and form-value protection, so we're on the safe side...).

Answer 3

Storing your session state outside of the app servers (Tomcat in your case), is a very common and recommended configuration for large scale websites. This is usually done in pursuit of an architecture style called Shared Nothing.

You can store your state in several different places: db, memcached, commercial replicated cache, etc. They all work with different mixtures of trade offs. Personally, I've had great success with memcached. Memcached is extremely fast and stable.

Generally, I opt for simplicity and use N memcache servers where N>1, say 2. As users log in, the app servers flip a coin to decide which server stores the users state. The cookie sent to the browser includes information to know which memcache server to route to from then on. Subsequent requests from the browser fetch state from the appropriate memcache server on each request. Should a memcache server fail, the user will have to login again as the app servers reselect a new server, but that is extremely rare.

Answer 4

Persisting sessions in the database limits your scalability. If scalability is not that important for you this (db + memcached) is a valid approach.

One thing you need to keep in mind when using nonsticky-sesions are concurrent requests: when you have e.g. ajax-requests (executed in parallel/concurrently) they will be served by different tomcats (due to non-stickyness) and therefore access the session concurrently. As long as you have concurrent requests that might modify the session you need to implement some kind of synchronization / session locking.

Perhaps this is of interest for you: I created the memcached-session-manager with the goal of both optimal performance and unlimited scalability. It can work with any memcached-compatible backend (e.g. also memcachedb, membase etc. or just memcached). Although it was originally created for a sticky-sessions approach, there's already a branch for nonsticky-sessions existing and a sample app showing how/that it works. Right now there's a thread on the mailing list on further improvements for nonsticky-sessions (handling of concurrent requests and preventing single-point-of-failure).