See intermixed.
On Tue, 13 Nov 2001, Tom Drake wrote:
> Date: Tue, 13 Nov 2001 13:27:23 -0800
> From: Tom Drake <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
> Tom Drake <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat: Distributed Session Management revisited
>
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, November 13, 2001 12: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");
>
> I believe that, in this case, it is incumbent upon the application to call
>
> session.setAttribute("foo", mo);
>
This violates the principle that the application programming model should
not change, but it's certainly feasible to say "if you want load balancing
to work on this container, you have to call HttpSession.setAttribute()
whenever you modify an attribute's properties".
By itself, though, this doesn't provide any support for locking against
simultaneous updates (i.e. what you do in "synchronized" blocks in a
single VM).
It's a little funny funny ... by the time we invent API to solve all these
problems, you've just defined a pretty fair chunk of the functionality of
EJBs ...
>
>
>
>
> | 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
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
