Steven Newton wrote:
> > So assuming the site requires "single sign-on". And that there are
> > several segmentations of the site, each of which could
> > be handled by a different web-app:
> >
> > I'm getting the impression that I'm supposed to do some
> > kind of magic with the session cookie. Is it necessary
> > to persist all of the session data, to be shared between
> > web-apps, in the database? Or is there a trick for finding
> > the in-memory session data for another web-app?
> >
>
> A database would be necessary if you want the session information
> to persist across server shutdowns,
That actually turns out not to be the case.
Tomcat 4.0 already has code to persist and restore sessions across a server
shutdown, or across the restart of a single application (triggered by a class
being changed in autoreload mode, or by an administrative command). It uses a
single disk file to save sessions to, or restore them from.
The only gotcha is that your session attributes need to be Serializable to be
saved and restored -- but you're going to need to do this in order to take
advantage of a server that supports migrating sessions between server instances
anyway.
> but if you just want to share
> it amongst web apps there are alternatives. You could, for example,
> set up a JNDI context where all web apps needing access to particular
> session information could store and retrieve session variables.
> There's a number of ways to share session without going to a database
> solution.
>
> > What's the rationale behind this architecture?
> >
>
> Security, for one. Multiple web apps running in the
> same application server are isolated from running into
> each others' space.
>
> s
Craig McClanahan
