Determines when the container should consider that session data must be replicated across the cluster.

Possible values are:

                    1 - "SET_AND_GET"
                    2 - "SET_AND_NON_PRIMITIVE_GET" (default value)
                    3 - "SET"
  
The rationale for this setting is that after a mutable object stored as a session attribute is accessed from the session, in the absence of a setAttribute call the container has no clear way to know if the object (and hence the session state) has been modified.
  
In all cases, calling setAttribute marks the session as needing replication.
  
SET_AND_GET is conservative but not optimal (performance-wise): it will always replicate session data even if its content has not been modified but simply accessed. This setting made (a little) sense in AS 4 since using it was a way to ensure that every request triggered replication of the session's timestamp. Since setting max_unreplicated_interval to 0 accomplishes the same thing at much lower cost, using SET_AND_GET makes no sense with AS 5.

SET_AND_NON_PRIMITIVE_GET is conservative but will only replicate if an object of a  non-primitive type has been accessed (i.e. the object is not of a well-known immutable JDK type such as Integer, Long, String, etc.) This is the default value.

SET assumes that the developer will explicitly call setAttribute on the session if it needs to be replicated. This setting prevents unnecessary replication and can have a major beneficial impact on performance, but requires very good coding practices to ensure setAttribute is always called whenever a mutable object stored in the session is modified.

Determines the granularity of what gets replicated if the container determines session replication is needed.

Possible values are:
                    1 - "SESSION" (default)
                    2 - "ATTRIBUTE"
                    3 - "FIELD"

The SESSION option indicates that the entire session attribute map should be replicated when any attribute is considered modified. Replication occurs at request end. This option replicates the most data and thus incurs the highest replication cost, but since all attributes values are always replicated together it ensures that any references between attribute values will not be broken when the session is deserialized. For this reason it is the default setting.

The ATTRIBUTE option indicates that only attributes that the session considers to be potentially modified are replicated. Replication occurs at request end. For sessions carrying large amounts of data, parts of which are infrequently updated, this option can significantly increase replication performance. However, it is not suitable for applications that store objects in different attributes that share references with each other. This is because if the attributes are separately replicated, when the session is deserialized on remote nodes the shared references will be broken.
  
The FIELD option is useful if the classes stored in the session have been bytecode enhanced for use by PojoCache.  If they have been, the session management layer will detect field level changes within objects stored to the session, and will replicate those changes. This is the most performant setting.

Whether the container should assume a JK-based software load balancer (e.g. mod_jk, mod_proxy, mod_cluster) is used for load balancing for this webapp. If set to true, the container will examine the session id associated with every request and replace the JvmRoute portion of the session id if it detects a failover.

The default value is null (i.e. unspecified), in which case the session manager will use the presence or absence of a jvmRoute configuration on its enclosing JBoss Web Engine (configured via server.xml) as indicating whether JK is used.

The only real reason to set this element is to set it to false for a particular webapp whose URL's the JK load balancer doesn't handle. Even doing that isn't really necessary.

Determines the maximum interval between requests, in seconds, after which a request will trigger replication of the session's timestamp regardless of whether the request has otherwise made the session dirty.  Such replication ensures that other nodes in the cluster are aware of the most recent value for the session's timestamp and won't incorrectly expire an unreplicated session upon failover. It also results in correct values for HttpSession.getLastAccessedTime() calls following failover.

A value of 0 means the metadata will be replicated whenever the session is accessed.  A value of -1 means the metadata will be replicated only if some other activity during the request (e.g. modifying an attribute) has resulted in other replication work involving the session. A positive value greater than the HttpSession.getMaxInactiveInterval() value will be treated as a likely misconfiguration and converted to 0; i.e. replicate the metadata on every request.  Default value is 60.

Defines when sessions are replicated to the other nodes.

Possible values are:

                 1. "instant" (the default)

                 2. "interval"

The typical value, "instant", replicates changes to the other nodes at the end of requests, using the request processing thread to perform the replication. In this case, the "snapshot-interval" property is ignored.

With "interval" mode, a background task is created that runs every "snapshot-interval" milliseconds, checking for modified sessions and replicating them.

Note that this property has no effect if replication-granularity is set to FIELD. If it is FIELD, "instant" mode will be used.

Fully qualified class name of the implementation of the ClusteredSessionNotificationPolicy interface that should be used to govern whether servlet specification notifications should be emitted to any registered HttpSessionListener, HttpSessionAttributeListener and/or HttpSessionBindingListener.

Event notifications that may make sense in a non-clustered environment may or may not make sense in a clustered environment; see JBAS-5778 for an example of why a notification may not be desired. Configuring an appropriate ClusteredSessionNotificationPolicy gives the application author fine-grained control over what notifications are issued.

In AS 5.0.0.GA the default value if not explicitly set is the LegacyClusteredSessionNotificationPolicy,which implements the behavior in previous JBoss versions. In the next AS 5 release the intent is to change this to IgnoreUndeployLegacyClusteredSessionNotificationPolicy, which implements the same behavior except for in undeployment situations during which no HttpSessionListener and HttpSessionAttributeListener notifications are sent.