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
|