tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach>
Subject Re: Are Sticky Sessions really necessary?
Date Sat, 03 Nov 2007 16:54:07 GMT
Hi Len,

the normal servlet spec conform purpose is to handle administration  
down, app version migration or
handle real crashes without lost your user session/context! This  
means not that tomcat replication cluster can't handle your "request  
stateless" szenario. It works
with speziell application, but to build those application is a very  
hard job. You can test it with pooled replication mode, but it's high
risk to have inconsistence at normal runtime. You must have good  
synchronization points to handle multiple request at same session at  
lots of threads and processes.  Please, check how your browser client  
interact exactly with your application. At  my experience the sticky  
session constraint help to have a better and controlled server env :-)


Am 03.11.2007 um 16:16 schrieb Len Popp:

> But isn't the purpose of session replication to allow different
> servers to handle the session? If not, what's it for?
> -- 
> Len
> On 11/3/07, Peter Rossbach <> wrote:
>> Hi,
>> It is not only ineffizient and a risk, Read 7.7.2 at the spec:
>> SRV.7.7.2 Distributed Environments
>> Within an application marked as distributable, all requests that are
>> part of a session
>> must be handled by one Java Virtual Machine1 ("JVM") at a time. The
>> container
>> must be able to handle all objects placed into instances of the
>> HttpSession class
>> using the setAttribute or putValue methods appropriately.
>> ....
>> regards
>> Peter
>> Am 02.11.2007 um 22:37 schrieb Len Popp:
>>> You can indeed use session replication without sticky sessions, and
>>> the session data will be copied to all the Tomcat servers.  
>>> However it
>>> may be inefficient. You probably have to use synchronous replication
>>> to ensure the session data is consistent across the cluster, which
>>> adds latency to the requests. And there could be a lot of extra
>>> network traffic in the cluster if it's busy (which it is, otherwise
>>> you wouldn't be doing load balancing).
>>> (I haven't used session replication in a high-load situation. Maybe
>>> someone else can tell us how well it works.)
>>> --
>>> Len
>>> On 11/2/07, Stephen Wick <> wrote:
>>>> The Tomcat 5.5 "Clustering/Session Replication Guide" says, "Make
>>>> sure
>>>> that your loadbalancer is configured for sticky session mode."
>>>> However,
>>>> I don't see the term "Sticky" sessions anywhere in the Servlet  
>>>> 2.3 or
>>>> 2.4 specifications.
>>>> Are sticky sessions really required for clustering to function
>>>> properly
>>>> in Tomcat 5.5?  I thought that session replication would eliminate
>>>> any
>>>> need to direct a client session to one node in a cluster.
>>>> If not, can we adjust the documentation to indicate that Sticky
>>>> sessions
>>>> are optional, for the appropriate reason (I'm guessing the  
>>>> advent of
>>>> session replication in tomcat.)
>>>> I am asking this question because I am having trouble with Sticky
>>>> sessions in my load balancer, and I need to know whether or not I
>>>> should
>>>> pursue fixing this feature.  If tomcat doesn't really require  
>>>> sticky
>>>> sessions, then I can leave my load balancer alone.  If tomcat does
>>>> need
>>>> the feature to function properly, then I need to go to some
>>>> additional
>>>> expense to resolve the issue with my load balancing appliance.
>>>> Thank you for your time and expertise.
>>>> Stephen Wick
>>>> Interactive Developer
>>>> Nicholson Kovac, Inc.
>>>> References
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message