>users will fail over to another box with nothing in their session. In some applications this is an acceptable risk if you have high uptime servers and very few code releases. If you however want a solid insurable "customer session" then using sticky sessions is not an option unfortunately.
Chris McCormack -----Original Message----- From: Paul McCulloch [mailto:[EMAIL PROTECTED] Sent: 08 July 2004 14:54 To: 'Struts Users Mailing List' Subject: RE: some best practices questions The solution to this problem is to use a load balancer which knows about sessions. mod_jk2 for Apache does this very well. With sticky sessions enabled the first request in a session goes, as you say, to a low load box. All subsequent requests in that session will be sent to the same box. You don't have to make *any* changes to your application to support this. The only downside (vs a 'real' cluster) is that in the event of a box dying users will fail over to another box with nothing in their session. Paul > -----Original Message----- > From: McCormack, Chris [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 14:09 > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: RE: some best practices questions > > > >3) Users session is on that machine. The url for that > machine is machine123.msn.com. > > You missed a few steps which outlines the problem with > clustered servers not being able to use session scope for a user : > > -a user types in their login details on www.msn.com and hits "GO". > > -the request hits www.msn.com and the load balancer assigns > the request to a low load box and rewrites > the url and forwards the request on ie serv1.msn.com > > -the request lands at serv1.msn.com and the application on > serv1.msn.com services the request and pops a few things in > session scope for use later now it knows who the user is > because they just logged on, it then sends back a valid > response with the users page. > > -the user gets his response and decides to click their > personalised news link www.msn.com/news > > - we are then submitting a new request to www.msn.com. The > load balancer(front processor) may decide that serv1.msn.com > is under load or is not available for this request and sends > to serv24.msn.com. > > - The users session is not on this machine so the application > cannot obtain the info it needs about the user to proceed > with the request. The application has to : > a, get the user to relogin > b, fail horribly or with a nice smiley message :P > > The ways around this have been to : > > c, use black magic to retrieve the users session > > by black magic I mean cookies with a state id in/a sessionid > in the httpheader/session id in a url parameter/hidden form > field on a page that matches to a database/file/static > storage record containing the users session information. > > The point is if you use load balanced application server > clustering its not straight forward to implement session > handling and everyone does it differently subject to their > applications needs. > > Chris McCormack > > -----Original Message----- > From: Bryan Hunt [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 13:00 > To: Struts Users Mailing List > Subject: Re: some best practices questions > > > The main arguments that people have against session storage > is the following > > a) Excessive memory consumption limits scallability. > True, just don't go crazy storing whole db's and stuff in there. > > b) Sessions can not be shared by webservers in clustered environment. > > Clustered webservers with shared sessions are such a myth/stupid idea. > Do it like hotmail. > > 1) Request comes in to one of the front processor > machines selected by > DNS server with multiple resolves for the same address. > > 2) Choose a machine that that has resources to spare. > > 3) Users session is on that machine. The url for that machine is > machine123.msn.com. > > 4) User logs off, the next time they come back their session is on > some other machine. > > I fail to see what the point of sharing sessions between machines is ? > Even if the machine crashes, they just enter in the initial > address (ie > hotmail.com ) and get sent to a working machine. > > So my point is ... what's so bad about sessions ? > > Also if session ties you to a machine then file storage is > twice as bad. > > --b > > > > > > *********************************************** > This e-mail and its attachments are confidential > and are intended for the above named recipient > only. If this has come to you in error, please > notify the sender immediately and delete this > e-mail from your system. > You must take no action based on this, nor must > you copy or disclose it or any part of its contents > to any person or organisation. > Statements and opinions contained in this email may > not necessarily represent those of Littlewoods. > Please note that e-mail communications may be monitored. > The registered office of Littlewoods Limited and its > subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. > Registered number of Littlewoods Limited is 262152. > ************************************************ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ********************************************************************** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *********************************************** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. ************************************************ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
