This would be a great addition for Tomcat.
(AFAIK distributed sessions are not supported in Tomcat)
When you talk about session replicating, have you thought
about the method to use for it?

Regards,
Gummi Haf

------------------------------------------
Gudmundur Hafsteinsson - [EMAIL PROTECTED]
Dimon Software - www.dimonsoftware.com

"... 'cause that's what tiggers do the best!" - Tigger
------------------------------------------






[EMAIL PROTECTED]
16.12.2000 23:41
Please respond to tomcat-dev

 
        To:     [EMAIL PROTECTED]
        cc: 
        Subject:        Saving sessions across tomcat instances
Hi all,
 
I'm wondering whether tomcat can store session information in different 
tomcat instance?
 
IMHO the answer is NO. Therefore I would like to share my thought on: 
Saving sessions across tomcat instances.
 
A month ago I have posted patch to allow tomcat load balancing when 
working with no cookies. This patch is the basic block to my thoughts on 
creating infrastructure to allow moving the session object between tomcat 
instances. The patch I posted added the tomcat 'name' (jvmRoute) to the 
sessionID, so if you are working with load balancing configuration you 
should see the tomcat name appear at the end of the seesionID. Mod_jk (and 
jserv) use this trail to forward the request to the right tomcat instance.
 
Allowing tomcat to replicate its session to another tomcat will allow real 
Tomcat redundancy and high-availability.
 
My thoughts are to build the system in the following steps:
1.      SessionManager to support dump and restore.
a.      SessionManager will dump its session into file while taking tomcat down. 
(Finalize ?? or SessionSerializer)
b.      Arrange SessionManager to restore its sessions while coming up. 
(Constructor ?? or SessionSerializer)
2.      SessionManager to support merge.
a.      Allow SessionManager to merge its sessions store with another store got 
from outside. This will allow one SessionManager to send its sessions to 
another SessionManager periodically. This will be done by extending the 
cleanup process to send all sessions to the other Tomcat. Periodic run 
intervals will come from configuration file.
3.      Sending only new session to other tomcat
a.      The periodic process will send to other tomcat only session 
created/touched from last run.
b.      This will be done for session that access time is newer than the last 
cleanup run, and older than request processing period, lets say 3 seconds 
(to make sure the servlet is not changing the object now). Time variables 
will come from configuration file.
4.      Read replication configuration from configuration file.
a.      Allow to define which tomcat sends session information to which tomcat.
b.      Configure mod_jk to send requests to second tomcat if first one is not 
responding.
 
I'm going to implement this against tomcat 3.3 (checking out 
Jakarta-tomcat, not tomcat_32 from CVS. Am I right? Or there is tag for 
33?)
I would like to get you thoughts whether this is required or not, any 
implementation hints, or any other requests before I'm getting into 
implementing this.
Please let me know what you think.
 
 
________________________
Shai Fultheim
Chief Technology Officer
BRM Seed
 
E-Mail: [EMAIL PROTECTED]
Mobile: 972-53-866-459
Office: 972-2-5891-459
 


Reply via email to