hi shai,
    i had the same problem i set up http session between two tomcats and
the session was not maintained.
So what silly thing i did ( since i did not have time to think of optimal
alternative) was that i stored the session ids of a servlet in a vector and
i asked the client servlet to send me the session id each time it communicated. After my work in the session is finished i removed the
session id from the vector. creating a new session. Is this idea good.
any draw backs?
thanks in advance.
 

[EMAIL PROTECTED] wrote:

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.
    1. SessionManager will dump its session into file while taking tomcat down. (Finalize ?? or SessionSerializer)
    2. Arrange SessionManager to restore its sessions while coming up. (Constructor ?? or SessionSerializer)
  2. SessionManager to support merge.
    1. 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
    1. The periodic process will send to other tomcat only session created/touched from last run.
    2. 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.
    1. Allow to define which tomcat sends session information to which tomcat.
    2. 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

-- 
  ____________________________________________________________________
  |                                         |Hostel address:-         |
  | N.Rajesh Babu                           |  room no 111,           |
  | M.Tech , Dept of cse                    |  manas hostel,          |
  | Indian Institute of Technology Guwahati |  IIT Guwahati,          |
  |  Guwahati , ASSAM                       |  North Guwahati,        |
  |                                         |  Guwahati, Assam        |
  | ph :- home   |  0091-8623-41013         |  India                  |
  |       hostel |  0091-361-790124         |                         |
  | e-mail:- [EMAIL PROTECTED]              |                         |
  |          [EMAIL PROTECTED]           |                         |
  |          [EMAIL PROTECTED]      |                         | 
  |          [EMAIL PROTECTED]       |                         |
  |_________________________________________|_________________________|
 


Reply via email to