tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <>
Subject Re: Tomcat: Distributed Session Management revisited
Date Tue, 13 Nov 2001 16:55:26 GMT

Interesting discussion, it's good to see some on this distribution
issue, the devils always in the detail!  See comments

> | > But how would they know where the sessions ended up????
> All session managers keep a copy of all sessions. So, it doesn't matter
> which server a client talks to.

This idea of all SM's keeping copies of all sessions seems to go against
the point of having multiple SMs.  If increasing SMs is a way to provide
redundancy then this approach removes scaleability.  If increasing SMs
is to provide scaleability then having all sessions in all managers
won't work.  If you hit the bottleneck then you can't just add a new SM
to solve any load problem.  Why do SMs need to have copies of all, why
not just keep those sessions that are created in the SM there.  The
session ID can contain the SM service id which can be adopted by a
service that takes over from any failed one.

> If we become more granular, such that individual session attribute changes
> are communicated independantly (rather than a complete copy of the session)
> our need for locking may diminish. However, I'm still not convinced about
> the need for locking to begin with.

Agreed, I am not convinced locking is necessary either, I have a
distributed session implementation that uses session proxies that talk
to services and pass only deltas of changes to the session.  Session
services notify proxies that have the session of changes which get
refreshed lazily when required.  SMs are remote over RMI and the proxy
is local to the container.


Antony Bowesman
Teamware Group
phone: +358 9 5128 2562
fax  : +358 9 5128 2705

intra / extra / Internet solutions at

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message