tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Olliver" <>
Subject RE: DistributedManager - Session Persistence and Realm
Date Mon, 05 Nov 2001 23:36:15 GMT
So I guess the goal of distributed session management is to gracefully
survive fail-over at times of trouble rather than 'random' or 'least load'
request scattering.

If Session Data and Realm are managed separately then both must be taken
into account to enable 'gracefull fail-over' of a secured application. Is
this on the agenda for the DistributedManager solution ?

While trying out the JDBC Persistent Sessions Storage, I found that the
current JDBC Realm implementation became broken - as soon as session data
was serialised to DB it seemed the authentication challenge always comes
back. With Manager logging turned up full it seems like sessions other than
my test browsers were being created and destroyed - pretty much in sync with
the recurring auth challenge - is this something to do with the realm
implementation (I have not looked under the covers yet.. ) ?

Are persisted sessions and realm currently imcompatible, or am I doing
something wrong (if so I must post config details next time).


-----Original Message-----
From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
R. McClanahan
Sent: 30 October 2001 04:02
To: Tomcat Users List;
Subject: Re: DistributedManager - Session Persistence

On Tue, 30 Oct 2001, Andy Olliver wrote:

> Date: Tue, 30 Oct 2001 01:07:16 -0000
> From: Andy Olliver <>
> Reply-To: Tomcat Users List <>,
> To:
> Subject: DistributedManager  - Session Persistence
> Hi
> I have been experimenting with JDBCStore, for persistent session storage.
> I think the goals of this module are different to my own - I wish to work
> with a 'shared session store' in order to persist session data when
> with multiple tomcat instances in 'round-robin' load balancing.
> >From the docs I am assuming that the primary goal of the module is to
> persistence across re-start, and to save memory usage by swapping out idle
> sessions (- please put me right if this is not a correct interpretation),
> rather than for immediate writing of changes to shared storage for use by
> other engines.
> Has anybody else needed to solve this problem and come up with a workable
> solution?

One of the things to keep in mind is the Servlet Specification
requirements related to distributed servers.  The most important one (for
the purposes of this conversation) is in Section 7.7.2:

    Within an application marked as distributable,
    all requests that are part of a session must be
    handled by one virtual machine at a time.

In other words, implementing an environment where simultaneous requests to
the same session can be handled on different servers would violate this
requirement.  The bottom line is that you're going to need some help from
your front-end server/router/whatever to maintain session stickiness to a
particular server at a particular point in time (although it is legal for
a session to be migrated "in between" requests).

Besides the spec requirement, you're going to have horrendous race
condition problems if you try to build something like this.  Consider the
following two things happnening simultaneously:

     On Server "A"                  On Server "B"
     ------------------------       -------------------------
     Get attribute "foo"            Get attribute "foo"
     Modify a property "bar" of     Modify a property "bar" of
           this object                    this object

On the same JVM, it's very easy to avoid problems -- simply synchronize as
necessary.  But Java does not provide you any synchronization primitives
that work across JVMs.

> On a similar thread - when sessions are saved to db and tomcat restarted,
> any form-based realm authentication status is lost, so realm users are
> required to log in a second time. Is there a neat work around for this? I
> thinking of copying a Principle object to user session for permanent
> reference, but I can't see a way of preventing a second challenge without
> modifying the realm implementation - again any pointer much appreciated.

The Principal object is owned by the Realm, not by the application.
Therefore, it's not going to be feasible to do what you want here either.

> bests
> andy.


To unsubscribe:   <>
For additional commands: <>
Troubles with the list: <>

View raw message