You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Andy Olliver <an...@slyfrog.com> on 2001/11/06 00:36:15 UTC
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 <an...@slyfrog.com>
> Reply-To: Tomcat Users List <to...@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: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
RE: DistributedManager - Session Persistence and Realm
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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 <an...@slyfrog.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
> andy@slyfrog.com
> To: Tomcat Users List <to...@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 <an...@slyfrog.com>
> > Reply-To: Tomcat Users List <to...@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: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>