In this article, I am going to explain how can you persist/share tomcat session state between multiple instances, and improve your site performance.
Persisting your session state outside of the tomcat servers is a very common and recommended configuration for large scale websites. This is usually done in pursuit of an architecture style called Shared Nothing.
In my post configuring multiple tomcat application servers with Apache HTTP server I’ve explained how to load balance multiple tomcat with apache web server. There is a common problem user found while load balancing with multiple tomcat servers, of sticky and non-sticky sessions on tomcat. So what is these sticky and non-sticky session actually?
lets have an example, suppose we have three tomcat servers to serve the request for our website behind a single apache server. And all the web request will come to apache server and the load balancer will decide which actual tomcat server will serve the request.
Now suppose we have three request request_A, request_B, and request_C, now what the load balancer should do to serve these requests? Should these requests served by different tomcat server because we also have three tomcat servers, or should these all go to same server? Here comes the role of sticky and non-sticky sessions.
think about if the request_A is for login and request_B is for user_dashboard page, and request_C is some other user’s page request, and what happened if request_A(login) served from server-1 and request_B(dashboard) served from server-2? is the dashboard will be served to the user or server-2 will send user a login page because of no active logged-in session on the server.
Sticky Session
Sticky session refers to a common feature of many load balancing solutions for handling session based web requests.
In case of sticky session, load balancer manage and route all the requests for a particular session to the same tomcat server that executed the first request for that session.
Non-sticky Session
In case of non-sticky session all requests can be served from different tomcat servers, and each server will create a new session object for the request to serve. These three sessions are purely independent and doesn’t know about each other, and there is no direct way of knowing what is there in the session object of the other tomcat server.
This post is about, how to synchronize between these server sessions, and how to write/read the session data into a layer which is common to all.
non-sticky session are concurrent by nature, and when you are using parallel requests they will be executed by different tomcat servers and session will be used concurrently due to non-stickyness. But if you are having concurrent parallel requests that might change the session, you need to implement/use some kind of synchronization or session locking mechanism.
Persist/share tomcat session state
There are many solutions exists to persist/share tomcat session state between multiple instances. Some most common and widely used solutions are: database, memcache, cassandra, redis, mongo, etc.
Personally I didn’t support for database to store session state, as persisting sessions in the database limits your scalability. If you still want to store session in a database and scalability is not that important for you, I prefer to use a combination of database + any caching platform.
I’ve written separate posts for some commonly used solutions, because writing in a single post will make this post very large, so follow the corresponding post link for more details.
- Manage tomcat session replication using memcached (coming soon)
- Manage tomcat session replication using cassandra (coming soon)
- Manage tomcat session replication using redis (coming soon)
- Manage tomcat session replication using mongo (coming soon)
They all works good, and this is up to you which one suits you the best.
References: