how to share sessions between independent tomcat instances

Question

Hi

I have several tomcat instances running in physically independent machines.

I want to configure the tomcat to share sessions between this instances.

I have tried to configure org.apache.catalina.session.PersistentManager from http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html. But I only see the session file when I shutdown the tomcat instances and I don't know if the instances are sharing this session. I think not. Because It doesn't make sense if tomcat writes down the session only on shutdown.

The other thing that I found is the cluster-howto but I can't do that couse the machines can't see eachother. They only shares a storage path to use.

Other thing that I think I can do is to implement a manager but it seems a litle bit tricky.

I have to add that I am using tomcat for deploying grails war files and I am using the grails session. I thing it has something to do with Spring

So, the question is: What is the best thing you think I can do to accomplish more effectibly the task? Or maybe I am missing something? Can you give me any pointer?

Answer 1

You have the F5 Big IP doing the load balancing in front of the tomcat servers, so it will handle the sessionID for you by sending you back to the correct Tomcat server. Use the sticky-round-robin algorithm.

As per the usecase in your comments -

What I am trying to do is to save some data in session, then redirect to a login server, who in a success scenario it redirects to my servers. And my concern is what happend if the load balancer redirects the request to the server that doesn't previously saved the needed data in session. Maybe sticky session is what I need. So: can I configure sticky session in a non tomcat-cluster enviromnent?

At the successful login - you redirect back first to the BigIP. It will pick up the sessionID from the browser. It will send you to the correct Tomcat and you should be able to retrieve the session data.

If not, looks like you need to store the "sessionID" itself against some "user Id" in a database but thats a bad design. I think the former should work