Coherence Web Cache Configuration

Coherence*Web uses the caches and services defined in the session-cache-config.xml file to implement HTTP session management. This file is deployed under WEB-INF/classes in either the instrumented web application or shared WebLogic Coherence*Web SPI library.

Caches

session-management:This cache is used to store internal configuration and management information for the session management implementation. This information is updated infrequently; therefore, it is a replicated cache by default.

servletcontext-storage:If ServletContext attribute clustering is enabled (it is disabled by default), this cache is used to store ServletContext attributes. This cache is replicated by default, as it is expected that there will a few read-mostly attributes.

session-storage:This cache is used to store session models. By default it is mapped to a near cache backed by a distributed cache since it is expected that a container will access and modify a subset of sessions multiple times (assuming that sticky session load balancing is configured.)

session-overflow:If the coherence-sessioncollection-class parameter is set to com.tangosol.coherence.servlet.SplitHttpSessionCollection, this cache will hold "large" session attributes. By default, session attributes larger than 1K will be stored in this cache. This is configured as a distributed cache.

session-death-certificates:Recently expired session IDs are stored in this cache in order to prevent reuse of a recently used session ID. By default, each storage node will hold up to 4000 session IDs, and session IDs will be evicted after 24 hours. This is configured as a distributed cache.

local-session-storage:This local cache is used to store session models that are considered to be "local" by the configured (if any) coherence-distributioncontroller-class.

local-attribute-storage:This local cache is used to store attributes that are not distributed. This can happen under two conditions:
1.A coherence-distributioncontroller-class is configured. Attributes for "local" sessions will be stored in this cache.
2.A non-serializable attribute is set on a distributed session. If coherence-sticky-sessions and coherence-preserve-attributes are set to true, this attribute will be placed in this cache.

Services

ReplicatedSessionsMisc:This replicated service is used by the session-management and servletcontext-storage caches.

DistributedSessions:This distributed service is used by the following caches:
•session-storage
•session-overflow
•session-death-certificates

The tangosol.coherence.session.localstorage system property controls whether or not a JVM will store and manage data for these caches. Under most circumstances, this should be set to false for web container JVMs. See Coherence*Web Deployment Topologies for more details.

SessionOwnership:This invocation service is used by the sticky session optimization feature (if coherence-sticky-sessions is set to true).

Coherence Web: Starting seperate Coherence Clusters for multiple applications deployed in the same Weblogic Server

The procedure differs between Weblogic Version 10.3.2 and later. In 10.3.3 and later, the process is well documented and straight-forward due to active-cache integration. But, I could find documentation on Weblogic 10.3.2 and previous versions but the challenge is how run multiple Coherence clusters with different configuration or in Coherence terms, how to put the below mentioned in the Application (EAR/WAR) files:

-session-cache-config.xml
-tangosol-coherence-override.xml

Both the above configuration files should hold the configuration for the cluster and cache topology to be used by this Application. In order to make it possible, create a jar file and include it in the EAR/META_INF/lib folder. This would allow you to override the cache configuration available in the coherence-web-spi and also provide the "tangosol-coherence-override.xml" for Coherence.

The above mentioned steps can also be used when you don't want your EAR/WAR(s) to use the Session objects of other EAR/WAR(s). In this way, you will be able to create multiple clusters with different configuration suited for different applications

Documentation on Coherence Web with Weblogic versions (10.3.3 and higher or 10.3.2 and lower)

There is a tighter integration between Weblogic and Coherence*Web with the introduction of active-cache in Weblogic 10.3.3 and above. In the lower versions of Weblogic, these features and integration with active-cache is not available and documented. You can find the documentation at below links:

Weblogic 10.3.3 and above

Weblogic 10.3.2 and below

Coherence Web versus Application Server HTTP Session Management

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.

Overview of Coherence Web 3.7

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

1) Enables session sharing and management across different web applications, domains and heterogeneous application servers;
2) Brings Coherence data grid's data scalability, availability, reliability and performance to in-memory session management and storage;
3) Supports all the mainstream application servers such as Oracle WebLogic Server, IBM WebSphere, Tomcat etc. (Coherence Web Support Matrix);
4) Supports numerous portal containers including Oracle WebLogic Portal.
5) 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.);
6) 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;
7) Supports multiple advanced session models which define how the session state is physically managed, serialized and deserialized in the cluster;
8) Supports fine-grained session and session attribute scoping by way of pluggable policies

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

1) Your application works with large HTTP session state objects
2) You run into memory constraints, due to storing HTTP session object data
3) You want to offload HTTP session storage to an existing Coherence cluster
4) You want to share session state across enterprise applications and Web modules

Refer the below mwntioned links to read more about Coherence Web:

1) http://www.oracle.com/technetwork/articles/entarch/session-management-092739.html
2) http://coherence.oracle.com/display/COH35UG/Coherence*Web+Session+Models
3) http://tomhofte.blogspot.com/2009/11/oracle-coherenceweb-easy-in-memory.html

Other useful documents are listed below:

1) Coherence Web Push Replication:
2) Caching HTTP Sessions with Coherence Web 3.7 Example
3) Coherence Management from Weblogic Console
4) JMX Monitoring and Running Examples
5) Customer Success