Oracle Coherence 3.7: Coherence*Web Session Management

Oracle Coherence clustering and Coherence*Web


One common use case for Oracle Coherence clustering is to manage user sessions - conversational state - in the cluster. 


This capability is provided by the Coherence*Web module, which is a built-in feature of Oracle Coherence. 


Coherence*Web provides linear scalability for HTTP Session Management in clusters of hundreds of production servers. 


It can achieve this linear scalability because at its core it is built on Oracle Coherence dynamic partitioning.



What is Coherence*Web?


Coherence*Web is an HTTP session management module dedicated to managing session state in clustered environments. Built on top of Oracle Coherence, Coherence*Web:


•  Enables session sharing and management across different web applications, domains and heterogeneous 
   application servers;
•  Brings Coherence data grid's data scalability, availability, reliability and performance to in-memory session
    management and storage;
•  Supports all the mainstream application servers such as Oracle WebLogic Server, IBM WebSphere,  
   Tomcat, etc.;
•  Supports numerous portal containers including Oracle WebLogic Portal;
•  Allows session state to be managed in the various caching topologies available in Coherence (i.e. 
   Replicated, Partitioned, Near Caching, Read-Through, Write- Through, Write-Behind and Refresh-Ahead  
   Caching, etc.);
•  Allows storage of session data outside of Java EE application server – freeing up application server heap  
   space and enabling server restarts without session data loss;
• Supports multiple advanced session models which define how the session state is physically managed,   
   serialized and deserialized in the cluster;
• Supports fine-grained session and session attribute scoping by way of pluggable policies.


Coherence*Web is not a replacement for WebLogic Server's in-memory HTTP state replication services. However, Coherence*Web should be considered when an application has large Http Session State objects, when running into memory constraints due to storing Http Session object data, and/or have existing Coherence Cluster and would like to offload Http Session storage to a Coherence Cluster.

Coherence*Web is an alternative to WebLogic Server's in-memory HTTP state replication services. Consider using Coherence*Web if you are encountering any of these situations:

• your application works with large HTTP session state objects
• you run into memory constraints, due to storing HTTP session object data
• you want to off-load HTTP session storage to an existing Coherence cluster
• you want to share session state across EAR files.
  
  

Location of the WebLogic Server Coherence*Web SPI in Coherence Distribution

The Weblogic Server Coherence*Web SPI consists of the coherence-web-spi.war file, located in the coherence\lib directory in the Coherence distribution. The coherence.jar file, located in the same directory, is also necessary for enabling Coherence*Web functionality in WebLogic Server.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Requirements for using Coherence*Web SPI

The Coherence*Web SPI for Weblogic Server requires that a load balancer which enforces http session JVM affinity is running in front of the WebLogic Server tier. WebLogic Server ships with several different proxy plug-ins which will enforce JVM session stickiness.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

In Coherence*Web, the following default cache configurations are defined:

• The Coherence*Web SPI for WebLogic Server is configured with local-storage disabled. The server will serve requests and will not be used to host data. This means a Coherence cache server must be running in its own JVM, separate from the JVM running WebLogic Server.
• The timeout for requests to the cache server to respond is 30 seconds. If a request to the cache server has not responded in 30 seconds, a com.tangosol.net.RequestTimeoutException exception is thrown.

The session-cache-config.xml file contains the Coherence cache configurations used by the Coherence*Web SPI. This file is located in the coherence-web-spi.war file under the WEB-INF\classes directory. 

Enter any cache configuration changes in the session-cache-config.xml file and then repackage it in the coherence-web-spi.war file.

Coherence*Web provides several session locking modes to control concurrent access of sessions. 

Both Coherence*Web and the Coherence*Web SPI employ Optimistic locking by default. This allows concurrent access to a session by multiple threads in a single JVM or multiple JVMs while prohibiting concurrent modification. 

By itself, the Coherence*Web SPI does not require a load balancer to run in front of the WebLogic Server tier. However, you will require a load balancer if you employ sticky session optimization with any of the non-Optimistic locking modes. The default load balancer enforces HTTP session JVM affinity, however, other load balancing alternatives are available. WebLogic Server ships with several different proxy plug-ins which enforce JVM session stickiness.