struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <andrew.david.h...@gridnode.com>
Subject RE: some best practices questions
Date Fri, 09 Jul 2004 04:12:38 GMT
My understanding (could be wrong on this of course) was that if you dont
have sticky sessions the container has to serialise the session to its
brethren as necessary. The serialisation is what scares most people, but
what scares me is how it knows when and what to serialise (plus the fact it
stops you using non-serialisable stuff!)

I gather many (all?) containers listen for calls to the
session.setAttribute() to determine when session contents have changed,
however when the modification is in some object that is 50 levels deep
inside some wierd structure that is being modified by something that knows
nothing (and should not know anything) of the session API... well thats a
nightmare! So if you give up the ability to do that kind of thing you
basically give up the potential for doing anything non-trivial in your
application at the presentation tier.

Probably not a problem for the millions writing shopping carts, but for this
rest of us who are trying to write real applications for which the GUI
requirements are painful enough in a rich client never mind on the web...
:-( Non-sticky sessions just arent practical. (I guess this is what Michael
was trying to tell me yesterday in regards to needing a new scope!)

Luckily for complex apps one isnt (usually) talking tens of thousands of
simultaneous client logins, and the rare loss of a client session is mainly
an annoyance and so long as they can log back in again and so long as the
business layer keeps going its usually ok (in these cases its usually the
business layer that does all the work and the UI is mostly for
administration of it). For shopping carts of course, a lost session is a
lost order, and there are vast number of potential users so the need for
failover and load balancing is quite genuine...



-----Original Message-----
From: McCormack, Chris [mailto:Chris.McCormack@littlewoods.co.uk]
Sent: Thursday, 8 July 2004 22:37
To: Struts Users Mailing List
Subject: RE: some best practices questions


>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:paul.mcculloch@axiossystems.com]
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:Chris.McCormack@littlewoods.co.uk]
> Sent: 08 July 2004 14:09
> To: Struts Users Mailing List; admin@revoltingdigits.com
> 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:admin@revoltingdigits.com]
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>


**********************************************************************
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


***********************************************
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message