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?
Tomcat provides in-memory session replication through a combination of serializable session attributes, "sticky sessions", which are provided by the load balancer, and specialized components configured in Tomcat's XML configuration files. We'll tackle each of these components one by one.
In session management, Tomcat creates a session id whenever client's first request gets to the server (However, other servlet containers may behave differently). Then it inserts this session id into a cookie with a name JSESSIONID and sends along with the response.
Tomcat's sessions are stored according to chosen session manager. If we pick the standard manager (StandardManager class saw previously), all session data will be saved into Java heap.
Session replication is a mechanism used to replicate the data stored in a session across different instances. However, the replicated instance must be part of the same cluster. When session replication is enabled in a cluster environment, the entire session data is copied on a replicated instance.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With