Cluster Node Isolation in Coherence*Web

When using Coherence*Web there are a number of deployment options to understand and consider, one of which is the concept of cluster node isolation.

This option will determine:
* The number of Coherence nodes that are created within an application server JVM.
* Where the Coherence library is deployed.

{anchor:ApplicationServerScopedClusters}
h2. Application Server Scoped Cluster Nodes
{section}
{column:width=50%}
With this configuration, all deployed applications in a container using Coherence*Web will be part of one Coherence node. This configuration will produce the smallest number of Coherence nodes in the cluster (one per web container JVM) and since the Coherence library ({{coherence.jar}}) is deployed in the container's classpath, only one copy of the Coherence classes will be loaded into the JVM, thus minimizing resource utilization. On the other hand, since all applications are using the same cluster node, all applications will be affected if one application misbehaves.

Requirements for using this configuration are:
* Each deployed application must use the same version of Coherence and participate in the same cluster.
* Objects placed in the HTTP session must have their classes in the container's classpath.
{column}
{column:width=50%}
!coherence-web-cluster-node-isolation-app-server-scoped.png!
{column}
{section}
{note:title=Be Careful}
This configuration should be considered very carefully and *never* used in environments where application interaction is unknown or unpredictable.

An example of such environment may be a deployment where multiple development teams are deploying independently written applications without coordinating and enforcing their conventions and naming standards carefully. With this configuration, all applications are part of the same cluster and the likelihood of collisions between namespaces for caches, services and other configuration settings is quite high and may lead to unexpected results.

For these reasons we strongly recommend either the [EAR Scoped|#EARScopedClusters] or [WAR Scoped|#WARScopedClusters] cluster node configurations. If you are in doubt as to which deployment topology to choose or if this warning applies to your deployment, please do not choose this configuration.
{note}

{anchor:EARScopedCluster}
h2. EAR Scoped Cluster Nodes
{section}
{column:width=50%}
With this configuration, all deployed applications within each EAR will be part of one Coherence node. This configuration will produce the next smallest number of Coherence nodes in the cluster (one per deployed EAR that uses Coherence*Web) and since the Coherence library ({{coherence.jar}}) is deployed in the application's classpath, only one copy of the Coherence classes will be loaded per EAR. Since all web applications in the EAR use the same Cluster node, all web applications in the EAR will be affected if one of the web applications misbehaves.

EAR scoped cluster nodes reduce the deployment effort as no changes to the application server classpath are required. This option is also ideal if you plan on deploying only one EAR to an application server.

Requirements for using this configuration are:
* The Coherence library ({{coherence.jar}}) must be deployed as part of the EAR file and listed as a Java module in {{META-INF/application.xml}}.
* Objects placed into the HTTP session will need to have their classes deployed as a Java EAR module in a similar fashion.
{column}
{column:width=50%}
!coherence-web-cluster-node-isolation-ear-scoped.png!
{column}
{section}

{anchor:WARScopedCluster}
h2. WAR Scoped Cluster Nodes
{section}
{column:width=50%}
With this configuration, each deployed web applications will be its own Coherence node. This configuration will produce the largest number of Coherence nodes in the cluster (one per deployed WAR that uses Coherence*Web) and since the Coherence library ({{coherence.jar}}) is deployed in the web application's classpath, there will be as many copies of the Coherence classes loaded as there are deployed WARs, thus resulting in the largest resource utilization out of the three options. However, since each deployed web application is its own cluster node, web applications are completely isolated from other potentially misbehaving web applications.

WAR scoped cluster nodes reduce the deployment effort as no changes to the application server classpath are required. This option is also ideal if you plan on deploying only one wAR to an application server.

Requirements for using this configuration are:
* The Coherence library ({{coherence.jar}}) must be deployed as part of the WAR file (usually in {{WEB-INF/lib}}).
* Objects placed into the HTTP session will need to have their classes deployed as part of the WAR file (in {{WEB-INF/lib}} or {{WEB-INF/classes}}).
{column}
{column:width=50%}
!coherence-web-cluster-node-isolation-war-scoped.png!
{column}
{section}