"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
|