Keif, have you considered using JavaSpace's as a shared storage mechanism.
I've just read some things on this and it seems like it might be a fit, but
I've not played with this yet. Just a thought. BTW, there is a good
article on this in one of the fairly recent Java Developer's Journal.
-----Original Message-----
From: Kief Morris [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 24, 2000 11:57 PM
To: [EMAIL PROTECTED]
Subject: RE: [RFC] Distributed sessions in Catalina
[EMAIL PROTECTED] typed the following on 11:16 PM 12/24/2000 +0200
>I'm planning to implement session replication (for tomcat 3.3) in the
>following steps:
Sounds like we should combine efforts, hopefully we can share as much
code as possible across both 3.3 and 4.0. My understanding is that the
architecture between the two is pretty different, and I've only looked at
4.0
to any depth.
>1. Having persistent session store. Letting tomcat store its session
>information to file and read it while coming up. Saving session will happen
>as soon as request will be finished. - This will let us restart tomcat
>without loosing sessions.
Sounds like a good option. Catalina saves sessions to file when the
container is restarted, it should be pretty easy to use that code to
implement this. Have you had a look at it? Check out
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardMa
nager.java,
in particular the load() and unload() methods.
>2. Let Tomcat send session information (for every request) to all other
>tomcat in a cluster. This will let apache (using mod_jk) to forward
requests
>to other tomcats after finding out that the original tomcat (by jvmRoute)
is
>not answering). - This will let us have redundancy into tomcat. Still we
>will need apache (mod_jk) in the picture.
How are you thinking to implement this? There are different network
topologies I could see using. If the servers share a file system, we could
just use the file store you describe in step 1. This would be simpler
to implement, but using the network and keeping the session data in
memory could be faster than using the disk.
>3. Letting tomcat forward requests to another tomcat based on jvmRoute. -
>This will let us having Tomcat without Apache around. The tomcat will be
>load balanced using external system (Local Director?), and forward requests
>to the relevant instance.
How will tomcat forward requests? Will it issue a redirect to the browser,
or will it proxy the connection? Either way seems like unnecessary
overhead. If you implement the session sharing in step 2, there should
be no need to forward requests - whichever instance of tomcat gets
the request should be capable of handling it.
You're actually moving a bit ahead of where I am at the moment.
I'd like to define an interface which will allow the implementation of
different methods for session sharing. A lot of the things you're doing
would go into specific implementations, but some implementations
might require a different, incompatible approach.
I'll chew on this some more, will try to get some code out between
family xmasing duties (am I sad or what?)
Kief
---
Kief Morris
Director of Technology
bitBull Ltd. http://www.bitBull.com
phone +44 020 7598 9938
fax +44 020 7460 4081
