tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Luc Rochat <j...@cybercable.fr>
Subject Re: [Catalina] Discussion -- Advanced Session Management Features
Date Tue, 01 Feb 2000 17:22:56 GMT
"Craig R. McClanahan" wrote:
> 
> Brill Pappin wrote:
> 
> >
> > What I'd suggest should be built into a Session management spec, it the
> > ability for all the servers participating in the "pool" to have a replica of
> > the current set of sessions. persistence also comes into play here.
> >
> 
> There is an interesting requirement in the 2.2 servlet spec regarding this
> topic, in Section 7.7.2:
> 
>     Within an application that is marked distributable,
>     all requests that are part of a session can only be
>     handled on a single JVM at any one time.
> 
> My reading of this implies that maintaining replicas of the session data
> content in all of the JVMs might be overkill.  The only time you *have* to copy
> the data around is when you are moving a session from one server to another --
> the rest of the time, your server is required to route all simultaneous
> requests for the same session to the same server.  Besides vastly simplifying
> things, this requirement also eliminates any need to be concerned about
> simultaneous updates to the same session being performed in two different JVMs
> at the same time.  Thus, there is never any need to reconcile these updates.
> 
> One possible reason you might want to copy the session information anyway is to
> provide some sort of fail-over service if a server dies.  It may be better to
> persist the data to the persistent store after any changes, and then share the
> persistent store between the JVMs, so a different server can "pick up" that
> session and continue processing it.  You still need to "write" the session
> information on some regular basis, but you only need to "read" it when the
> session is actually migrated.  Does that sound reasonable?
> 
I'll try to contribute to this discussion, as I am willing to contribute
to jakarta project, as I have got some spare time now.
One of the choices made in JServ was to keep things simple, and
eliminate any single point of failure & bottleneck. I really like the
idea of pluggable persistence for session contexts, but this has to be a
deliberate choice from the administrator, as this brings some new side
effects (single point of failure & performance issues).
One of the consequences of this former choice is a simple (compared to
Corba) architecture in load-balancing design, and maybe a manageability
loss of the entire system, but ensures that at least someone will answer
the request even if a node fails (LDAP, JavaSpace, RDBMS or whatever you
can keep your session data on).


Jean-Luc

Mime
View raw message