Coherence*Web supports a flexible data management model for HTTP session data. The HTTP session data is managed by an HttpSessionModel object, and the list of all HTTP sessions is managed by an HttpSessionCollection object. Coherence*Web includes three different implementations of these interfaces out of the box:
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.)
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 Monolithic Model is available starting with Coherence 2.5.
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.
To configure which session model to use: