"Duffey, Kevin" wrote:
> This is interesting Craig. I am wondering though what exactly ou mean by the
> 3rd item:
>
> > * In a distributable app, requests that are not part of a session can
> > be served by any copy of the app. However, if your request is part
> > of a session, all requests that are part of that session
> > *at a particular
> > point in time* must be served from the same JVM.
>
> I mean, my understanding of how session fail-over works is that when a
> request comes in, it can hit any server in the farm because the HttpSession
> is replicated to each of the servers in the farm.
No, that is not what the spec requirement says. (Leave out the issue of
failover
for a moment.)
Consider that you have your distributed app installed on servers A, B, and C.
Now,
a request (that is part of a session) comes in and is sent to developer B.
Next, before the current request (on server B) has been completed, another
request
comes in for the same session. The application server environment is *required*
to
do one of the following:
* Pass this request on to server B (because another request
for this session is already active there)
* Wait for the previous request to complete, migrate the session
to A or C, and then forward the new request to the new server
that owns that session.
Some application server environments might replicate the data for a particular
session across multiple servers, even though one server is still the primary
responsible party, in order to improve resiliency in the face of a server
failure,
but it is *not* legal to have requests for the same session being active on more
than one server at the same instant.
The reasoning behind this requirement is easy to understand when you consider
the
application developer's viewpoint: if you add an attribute to the user's
session,
you expect that change to be instantly visible to any simultaneous request that
is
being processed for the same session. This cannot happen if the requests are
being
handled on different machines, but when you're on the same machine it is the
same
session object being accessed by the requests.
> So I am not sure what it
> means by "request is part of a session"? My only thought is that if the
> request has already been started processing on the server..its tied to that
> server until the response goes back..meaning that if that server died, that
> request is NOT sent to another server..its lost.
The precise results of a server going down are based on the architecture of your
selected platform -- there's nothing in the spec that says what happens here.
> However, if I am correct in
> understanding that, that means that if the same user submits another request
> and the initial server that created the users session is no longer
> available, the users request is sent to another server in the farm and does
> not see any difference on their end..the 2nd server has the same HttpSession
> objects for that user as did the one that is no longer available. Is this
> correct?
Failover support is one of the places where app server vendors distinguish their
implementations -- it's not a spec related issue, so there is no common answer
to
what happens here.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
