struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McCulloch <>
Subject RE: some best practices questions
Date Thu, 08 Jul 2004 13:53:33 GMT
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.


> -----Original Message-----
> From: McCormack, Chris []
> Sent: 08 July 2004 14:09
> To: Struts Users Mailing List;
> Subject: RE: some best practices questions
> >3) Users session is on that machine. The url for that 
> machine is
> 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 and hits "GO".
> -the request hits and the load balancer assigns 
> the request to a low load box and rewrites 
> the url and forwards the request on ie
> -the request lands at and the application on 
> 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
> - we are then submitting a new request to The 
> load balancer(front processor) may decide that 
> is under load or is not available for this request and sends 
> to 
> - 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 []
> 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
>     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
> ) 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:
> For additional commands, e-mail:

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.
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:
For additional commands, e-mail:

View raw message