On 12/11/2001 11:14 pm, "Mika Goeckel" <[EMAIL PROTECTED]> wrote:
> I would vote for the cooperative approach, but I'd like to add some
> thoughts:
>
> Besides the primary session manager, there needs to be a backup session
> manager that captures the changes of sessions as well and is the crown
> prince of the primary session manager. This is to prevent sessions to be
> replicated to all other cluster instances (memory overhead) but to stay on
> the save side if the primary goes down (yep, both could crash, but what in
> live is 100%?). In that case the crown prince would take over and another
> cluster instance can take over the crown prince's role.
>
> Which server the primary manager is, should be either configurable or
> random. The cluster instances should be configurable. Multicast should only
> be used if the cluster instances are not configured to find out what other
> instances are there. The configuration should only specify the initial
> state, further instances should be addable at any time without the need to
> bring the cluster down.
That's exactly how CIFS works in terms of browsing lists... Every time a
node goes up or down, an election is "performed" and the one who wins takes
over the "primary" place.
The problem, though, is that in our case we also need to replicate data
across several managers, and not only the information exchanged over at
election...
> Another thought is, do sessions need to be replicated in whole, or could
> there be a way to replicate only the changes (network overhead). I know guys
> that store loads of things in sessions. We had a case where a whole search
> result (one complex object per row) was stored there, possibly up to a
> couple of megs...
That's definitely a problem, because if you replicate that session data over
to a N number of session managers, the growth is linear (N*(size+overhead)).
> RMI would be my first approach as well, but I would try to keep the
> communication details separated from the functional logic implementing the
> cluster. This would enable us later on to choose other means like JavaSpaces
> or JMS. RMI is the first choice if the cluster is near by, but what against
> a cluster over a WAN if the requirements allow slow/deferred replication?
> RMI could not do that job reliable.
Indeed... But you have to consider that the state of the session needs to be
lockable and transactional... Interesting... Think think think...
The session doesn't have a "commit" (freak, too bad), so, to we are unable
to know whether a particular servlet engine is getting that session for
reading or for reading/writing (and that complicates things, because
basically, we have to consider that all accesses to sessions are
read-writes, and in a distributed session environment, we need to lock data
around).
Let's assume (simple case ever) that we have two servlet containers (ServA
and ServB), and one session "manager" (single point of failure, let's call
it Sess).
ServA receives a request, gets its session from Sess and "locks" it, and
then the servlet "whops" gets into an infinite loop... The user, not seeing
anything coming back at him, hits "stop" and "reload", this time his request
goes to ServB...
Now, ServB tries to access the same exact session, but "whops", the session
is locked on Sess by ServA... What should we do? I believe we need to
introduce a concept of "timeout", in which a particular server is "allowed"
to lock the session for as long as he likes...
That to some extent is the root of the problem (concurrent accesses by
different servlet containers of the same session), once that is solved in an
acceptable manner (I don't see any other thing but "locking" sessions), then
the rest is "only" deciding down at network level how could we replicate and
access/lock sessions...
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
