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?
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... Mika :wq ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 8:41 PM Subject: Re: Tomcat: Distributed Session Management revisited > > > On Tue, 13 Nov 2001, Tom Drake wrote: > > > I want a distributed session store, where all sessions are known (or > > are knowable) by all members of the cluster, with a built-in > > fail-over mechanism? > > As you guys discuss this, don't forget a very important requirement in the > servlet specification with regards to distributable applications: > > [Servlet Spec 2.3, 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 effect, this means that a session can be migrated to a different server > only "between" requests. On a failure of the server currently handling > the session, you could migrate it to a different server, but this > operation must be atomic. > > 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]>
