Dan Milstein typed the following on 03:50 PM 12/24/2000 -0500
>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).
I agree that fault tolerance is the easier target, so session persistence is
going to be the first thing to implement. However I also think it's important
to keep the "big picture" in mind, rather than coding to meet the immediate
goal without considering the future.
If we implement session persistence and migration for fault tolerance purposes,
the same code will be very useful for full session sharing. In fact, my belief
(maybe mistaken) is that these features will provide the majority of what is
needed for full session sharing.
>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.
Fortunately, the servlet 2.3 spec simplifies this greatly by requiring that only
one instance of the servlet container can handle a request for a session at
a time. So the problem is reduced to locking shared sessions.
At the moment I'm focusing on implementing the FileStore class, which will give
me a better grip on how these should work.
Kief
---
Kief Morris
Director of Technology
bitBull Ltd. http://www.bitBull.com
phone +44 020 7598 9938
fax +44 020 7460 4081
