Coherence*Web provides four configuration options for controlling the behavior of HTTP sessions when accessed concurrently by multiple web container threads:
- Optimistic Locking - Allows concurrent access to a session by multiple threads in a single JVM or multiple JVMs while prohibiting concurrent modification.
- Member Locking - Allows concurrent access and modification of a session by multiple threads in the same JVM while prohibiting concurrent access by threads in different JVMs.
- Application Locking - Allows concurrent access and modification of a session by multiple threads in the same web application instance while prohibiting concurrent access by threads in different web application instances.
- Thread Locking - Prohibits concurrent access and modification of a session by multiple threads in a single JVM or multiple JVMs.
|In general, web applications that are part of the same Coherence cluster must use the same locking mode and sticky session optimizations setting. Inconsistent configurations may result in deadlock.|
The Optimistic Locking mode allows multiple web container threads in one or more JVMs to access the same session concurrently. This setting does not use explicit locking; rather an optimistic approach is used to detect and prevent concurrent updates upon completion of an HTTP request that modifies the session. When Coherence*Web detects a concurrent modification, a ConcurrentModificationException is thrown to the application; therefore an application must be prepared to handle this exception in an appropriate manner.
This mode can be configured by setting the coherence-session-member-locking parameter to false.
The Member Locking mode allows multiple web container threads in the same JVM to access and modify the same session concurrently, but prohibits concurrent access by threads in different JVMs. This is accomplished by acquiring a member-level lock for an HTTP session at the beginning of a request and releasing the lock upon completion of the request.
This mode can be configured by setting the coherence-session-member-locking parameter to true.
The Application Locking mode restricts access (and modification) to a session to threads in a single web application instance at a time. This is accomplished by acquiring both a member-level and application-level lock for an HTTP session at the beginning of a request and releasing both locks upon completion of the request.
The Thread Locking mode restricts access (and modification) to a session to a single thread in a single JVM at a time. This is accomplished by acquiring a member-level, application-level, and thread-level lock for an HTTP session at the beginning of a request and releasing all three locks upon completion of the request.
This mode can be configured by setting the coherence-session-thread-locking parameter to true. Note that setting this to true will imply a setting of true for both coherence-session-member-locking and coherence-session-app-locking.
Enabling Member, Application, or Thread Locking for HTTP session access indicates that Coherence*Web will acquire a cluster-wide lock for every HTTP request that requires access to a session; the exception to this is when sticky load balancing is available and the Coherence*Web sticky session optimization is enabled.
By default, threads that attempt to access a locked session (locked by a thread in a different JVM) will block until the lock can be acquired. If a timeout for lock acquisition is desired, one can be configured via the tangosol.coherence.servlet.lock.timeout system property in the container's startup script (for example -Dtangosol.coherence.servlet.lock.timeout=30).
Many web applications do not have such a strict concurrency requirement. For these applications, it is suggested to use the Optimistic Locking mode, which has the following advantages:
- The overhead of managing the cluster-wide locks on the sessions is eliminated, which will decrease the amount of work required to process each HTTP request;
- Requests can be load balanced away from a failing or unresponsive application server JVM to healthy application server JVMs without manually killing the unresponsive JVM or requiring it to release its cluster-wide lock on the session.
If Member, Application, or Thread Locking is a requirement for a web application that will be behind a sticky load balancer, Coherence*Web provides an optimization for obtaining the cluster-wide lock required for HTTP session access. By definition, a sticky load balancer will attempt to route each request for a given session to the same application server JVM that it previously routed requests to for that same session, which initially is the application server JVM that created the session. The sticky session optimizations takes advantage of this behavior by retaining the cluster-wide lock for a session until the session expires or until it is asked to release it. If, for whatever reason, the sticky load balancer sends a request for the same session to another application server JVM, that JVM will ask the JVM that owns the lock on the session to release the lock as soon as possible. This is implemented using an invocation service.
Sticky session optimizations can be enabled by setting the coherence-sticky-sessions parameter to true.