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