I have a bit of fear that you're getting into extremely complex waters here, and I
want to be sure you focus on the most useful bits first. Any form of distributed
synchronization of data is very difficult to get right, IMHO. Which is not to say
that it shouldn't be done, nor that your ideas below are off base, but rather that I
would vote for focusing on a smaller piece of the puzzle first.
For example, maybe fault tolerance is what seems most important (I think this would be
my vote). Then you can look at distributed sessions as being about:
- Allowing Tomcat instance A to back up session information to Tomcat instance B
- Configuring whatever device is load-balancing among Tomcat instances to know that
it should reroute A's session to B if instance A becomes unavailable.
(Incidentally, Shai Fultheim is working on this problem at the moment -- he's at
[EMAIL PROTECTED]).
This would be a good-sized (but manageable) bit of work, and would provide a very
important piece of functionality. It takes advantage of the existing solutions which
make sessions sticky to a particular tomcat instance (e.g. mod_jserv/mod_jk load
balancing, router-level solutions, etc).
If you do allow multiple TC instances to update a given session at once, you have to
worry about all sorts of hairy concurrency issues. Two requests from the same session
could come in simultaneously (from a framed site, for example). If one goes to A and
one goes to B, and both A and B try to update the session at the same time, the code
to handle that is going to be very complex.
The other main goal you cite is "improving performance by distributing load". Given
that there are currently several ways to make sessions sticky to particular TC
instances, I'm not sure how much work I would put towards that goal.
So I guess my summary is that I see session replication in support of fault tolerance
as very worth working towards, but a more general form of session replication as
someting to hold off on.
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
