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?
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).