Coherence*Web provides three 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.
- Thread Locking - Prohibits concurrent access and modification of a session by multiple threads in a single JVM or multiple JVMs.
Optimistic Locking (Default)
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.
Member Locking
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.
Thread Locking
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 both a member-level and thread-level lock for an HTTP session at the beginning of a request and releasing both 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 coherence-session-member-locking.
Usage Considerations
Enabling Member 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. By default, threads that attempt to access a locked session 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, using the Optimistic Locking mode has the following advantages:
- The overhead of obtaining and releasing cluster-wide locks for every HTTP request is eliminated;
- Requests can be load balanced away from failing or unresponsive JVMs to healthy JVMs without requiring the unresponsive JVM to release the cluster-wide lock on the session.
Sticky Session Optimizations
If Member 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 a request for a given session to the JVM that initially created it. The sticky session optimizations take advantage of this behavior by retaining the cluster-wide lock for a session until the session expires. If a request for the session lands on another JVM, that JVM will ask the JVM that owns the lock to release it 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.