A session model describes how Coherence*Web physically represents and stores session state in Coherence. Coherence*Web supports a flexible data management model for session state. The session state is managed by an
HttpSessionModel object, and the list of all sessions is managed by an
HttpSessionCollection object. Coherence*Web includes three different session model implementations out of the box:
- The Traditional Model – Stores all session state as a single entity but serializes and deserializes attributes individually.
- The Monolithic Model – Stores all session state as a single entity, serializing and deserializing all attributes as a single operation.
- The Split Model – Extends the Traditional Model but separates the larger session attributes into independent physical entities.
 | In general, web applications that are part of the same Coherence cluster must use the same session model type. Inconsistent configurations may result in deserialization errors. |
The Traditional Model
|
TraditionalHttpSessionModel and
TraditionalHttpSessionCollectionmanages all of the HTTP session data for a particular session in a single Coherence cache entry, but manages each HTTP session attribute (particularly, its serialization and deserialization) separately.
This model is suggested for applications with relatively small HTTP session objects (10KB or less) that do not have issues with object-sharing between session attributes. (Object-sharing between session attributes occurs when multiple attributes of a session have references to the same exact object, meaning that separate serialization and deserialization of those attributes will cause multiple instances of that shared object to exist when the HTTP session is later deserialized.) |
|
The Monolithic Model
|
MonolithicHttpSessionModel and
MonolithicHttpSessionCollection is similar to the Traditional Model, except that it solves the shared object issue by serializing and deserializing all attributes together in a single object stream.
As a result, the Monolithic Model is often less performant than the Traditional Model. |
|
The Split Model
|
SplitHttpSessionModel and
SplitHttpSessionCollection manages the core HTTP session data such as the session ID, creation time, last access time, etc. together with all of the small session attributes in the same manner as the Traditional Model, thus ensuring high performance by keeping that block of session data small. All large attributes are split out into separate cache entries to be managed individually, thus supporting very large HTTP session objects without unduly increasing the amount of data that needs to be accessed and updated within the cluster on each request. In other words, only the large attributes that are modified within a particular request will incur any network overhead for their updates, and (because it uses Near Caching) the Split Model generally does not incur any network overhead for accessing either the core HTTP session data or any of the session attributes. |
|
In Conclusion:
- The Split Model is the recommended session model for most applications.
- The Traditional Model may be more optimal for applications that are known to have small HTTP session objects.
- The Monolithic Model is designed to solve a specific class of problems related to multiple session attributes that have references to the same shared object, and that must maintain that object as a shared object.
See "Session Management for Clustered Applications" for information on the behavior of these models in a clustered environment.
