tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: DistributedManager - Session Persistence and Realm
Date Thu, 08 Nov 2001 06:50:29 GMT
I'm afraid that I'm not going to be much help on this set of issues -- the
only thing I've *ever* done with the DistributedManager classes is make
sure they compile; I have not (yet) had time to actually try them.

Craig


On Mon, 5 Nov 2001, Andy Olliver wrote:

> Date: Mon, 5 Nov 2001 23:36:15 -0000
> From: Andy Olliver <andy@slyfrog.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>,
>      andy@slyfrog.com
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subject: RE: DistributedManager  - Session Persistence and Realm
>
> 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).
>
> Andy
>
> -----Original Message-----
> From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> R. McClanahan
> Sent: 30 October 2001 04:02
> To: Tomcat Users List; andy@slyfrog.com
> 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 <andy@slyfrog.com>
> > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>,
> >      andy@slyfrog.com
> > To: tomcat-user@jakarta.apache.org
> > 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
> running
> > with multiple tomcat instances in 'round-robin' load balancing.
> >
> > >From the docs I am assuming that the primary goal of the module is to
> allow
> > 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
> am
> > 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.
> >
>
> Craig
>
>
> --
> To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>
>
>


--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message