On 13/11/2001 04:38 pm, "Mika Goeckel" <[EMAIL PROTECTED]> wrote:
> SNMP, ah ja. I've got no knowledge at all 'bout that, so fight with some
> other lobbyists :-)
Same here...
> SessionManager/ServletContainer dualism....:
> If we don't create a separate SessionManager residing in it's own JVM, but
> make it an integral capability of TC, we have the following benefits:
> - we save one copy:
> When a new session is created and we have a separate network of SMs, it
> needs to be copied to at least two SMs, if we have it in TC, it only needs
> to be copied to one other TC. (If we aim single redundance)
Indeed it would save bandwidth...
> - if one TC is the owner and the other the escrow, the owner never needs to
> ask if the session is uptodate or invalid, and it can't get stale. The
> replication of changes can be done after the request, so no time burden
> within the request itself.
> If the escrow want's to use the session, it only needs to inform the owner
> and they change roles (or if possible the escrow passes the request back to
> the owner)
> Frequently all servers ping their known escrows and owners to ensure they're
> still present.
The only problem I could see with that is synchronization of accesses from
different points, but I believe that is a solvable problem...
> - deserialisation should not be a problem, because in that ClassLoader
> Context, the user-session objects are known. (correct me if I'm wrong here)
Nope, you're right on that.
> AutoConf.... what about JNDI to register cluster nodes? It is around anyway.
> In that case an upcoming TC would just search the JNDI service for
> registered nodes with his own ClusterName, and register itself with it.
> Getting back a NamingEnumeration, it could decide itself, which of the
> others to link with.
One thing that can be done with my approach of multicasting is automatic
load balancing... To any request of "who can hold this session", each
manager can return a load index, and the decision on where the session
should be stored primarily and in replica should be based on that. Using
JNDI that can be done, but I don't want to end up in a situation where a
single host holds 80% of the sessions while the others are free... If the
managers could update their JNDI registrations with a "load" factor every X
seconds, that would be acceptable...
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
