Cool, sounds like having a primary owner and front-end redirection to it
solves that without lock distribution.
Means that an owner can't allow another TC to take over a session whilst
processing a request, but as he knows when he's finished, that's easy.
M.
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 9:31 PM
Subject: Re: Tomcat: Distributed Session Management revisited
>
>
> On Tue, 13 Nov 2001, Mika Goeckel wrote:
>
> > Date: Tue, 13 Nov 2001 21:19:35 +0100
> > From: Mika Goeckel <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Tomcat: Distributed Session Management revisited
> >
> > Hi Craig,
> >
> > am I understanding right, that "handling" in this context means the part
of
> > execution when the servlet's service routine is called? Would the
container
> > be allowed to fetch a session after the request has reached it but
before
> > the servlet's code is called?
> >
>
> It is not legal that the following scenario occur:
> * Two simultaneous requests for the same session.
> * Your container processes these requests in different JVMs.
>
> Details of when the restriction starts are basically dependent on the
> container's implementation -- but it's the result that must be obeyed.
>
> The reason for the restriction is pretty obvious when you think about
> this series of events (in chronological order):
> * Request 1 sent to server A
> * Request 2 sent to server B
> * Request 1 grabs session and calls session.setAttribute("foo", bar).
> * Request 2 grabs session and calls session.getAttribute("foo").
>
> On a server that properly implements the restriction, request 2 will
> always see the "foo" attribute, just as would occur in a non-distributed
> environment (which, by definition, would be processing both requests in
> the same JVM on different threads). Thus, from the application
> developer's perspective, you don't have to worry about the possibility
> that session attributes might be getting accessed or modified on multiple
> JVMs at the same time.
>
> It also means that the application can implement thread-safety locking
> with "synchronized" and have it work correctly on a single JVM or multiple
> JVM container. This isn't possible if the same session attribute can be
> accessed from multiple JVMs simultaneously.
>
> > Is it theological to ask if a proxy session object that would call the
> > methods of a session object in another JVM would violate that
requirement?
> > >From the application developers point of view he would not see a
> > difference...
> >
>
> It would be possible to do this for the HttpSession methods
> themselves (the container would know what's going on), but what do you do
> about session attributes?
>
> HttpSession session = request.getSession();
> MyObject mo = (MyObject) session.getAttribute("foo");
> mo.setName("bar");
>
> This cannot be done transparently unless MyObject class is actually an RMI
> or Corba reference, and even then the app would have to deal with the
> possibility of exceptions caused by the container's activities, not it's
> own.
>
> The whole idea is that the programming model for the application developer
> doesn't change in a distributable application. The fact that it makes
> life tougher on the container developer is what makes this particular
> functionality quite interesting to implement :-).
>
> > Mika
> > :wq
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
