Hi, 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. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] phone: +358 9 5128 2562 fax : +358 9 5128 2705 intra / extra / Internet solutions at www.teamware.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
