On 17/02/2007, at 3:32 AM, Dave Colasurdo wrote:
<snip>
Tomcat and Mod-jk provide the ability to have the load balancer
lock a particular httpsession (identified by session cookie) to a
specific cluster member. This cluster member will serve all the
requests for this session until the cluster member tops/fails and
failover to a new cluster member occurs. This "stickiness" is
quite useful for the case of multi-frame JSPs where it is important
that all concurrent requests are executing in the same JVM (as per
Java EE specifications). Hmmm, now that Terracotta provides the
concept of a global cross-node JVM, I'm wondering how important
this is now .. though still seems there would be performance
overhead in locking across JVMs.. so I think Sticky Session is
still useful..
Hi,
I think that if you have sticky load balancing, you do not need to
acquire a distributed lock to service concurrent requests: requests
are proxied to the node hosting the session state; each request
acquires a *local* read lock for the associated session (a read lock
is acquire such that requests bound to the same session can proceed
concurrently).
This is only when a request is received by a node where the session
state cannot be found that a distributed lock is to be acquired.
Thanks,
Gianny
