I have some applications currently using sticky sessions in tomcat 7. 
Everything works well except that restarting tomcat requires disabling mod_jk 
new sessions to an instance, waiting for sessions to expire and then several 
hours later restarting the instance. This process is slow and not resilient to 
unexpected failures.

So I want to persist sessions and allow session failure in the cluster. It 
appears that I have several approaches:

* JDBC
* memcache [1]
* DeltaManager
* BackupManager

I discounted JDBC quite quickly because I don't want to add any load to my 
existing database. DeltaManager seems simple, but I'm weary of sending lots of 
data to all the nodes in my cluster (there are 12) which aren't even running 
the application. So BackupManager seems better for my needs. However the 
documentation [2] suggests that BackupManager may not be as reliable.

Question 1: Is the documentation still correct after all these years of 
BackupManager being used? Is it still considered of lower reliability?


My next decision is between memcache and BackupManager/DeltaManager. memcache 
will require another service to be running, so slightly more maintenance and 
one more thing to fail. However memcache seems to be very commonly used and I'm 
not sure why. Are there benefits it will bring to this arrangement (such as 
visibility of live sessions in some sort of GUI) or something else I'm not 
seeing.

Question 2: Are there advantages to running memcache as a session store? I'll 
be continuing to use sticky sessions since I think that will be more reliable 
(the system will survive the failure of the session store/replication, whatever 
I choose).



Thanks for any advice

Ari




[1] https://code.google.com/p/memcached-session-manager/
[2] http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html
-- 
-------------------------->
Aristedes Maniatis
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to