----- 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 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]>
