Hi,
Craig, thanks for the reply. Makes perfect sense..and is infact a little
scary to think about. How the heck do you guarantee that if a user has two
windows open (from the infamous File/New Window option) that send the same
request, that both sends go to the same one server? I take it the
load-balancer needs to do this? I know our company just about a level-7
Cisco router for some $25K that supposedly handles all of this for us, but
we have yet to see it work. ;) At any rate, so basically even if the app
server supports HttpSession replication for fail-over support, it has
nothing to do with making sure that if two requests come in on two different
servers, even if the session data is on both, it sends the request from one
server to the "primary" server to be handled properly. So, what does control
this? Again..I assume the load-balancer is responsible for making sure of
this. If not..what would be?
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 23, 2001 5:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Session Object
>
>
> "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
>
===========================================================================
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
