Installation guide

ManualsBrandsRed Hat ManualsComputer equipmentNETSCAPE ENTERPRISE SERVER 6.1 - NSAPI PROGRAMMER GUIDE

<!DOCTYPE jboss-web PUBLIC

"-//JBoss//DTD Web Application 5.0//EN"

"http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">

<jboss-web>

<replication-config>

<cache-name>custom-session-cache</cache-name>

<replication-trigger>SET</replication-trigger>

<replication-granularity>ATTRIBUTE</replication-granularity>

<replication-field-batch-mode>true</replication-field-batch-mode>

<use-jk>false</use-jk>

<max-unreplicated-interval>30</max-unreplicated-interval>

<snapshot-mode>INSTANT</snapshot-mode>

<snapshot-interval>1000</snapshot-interval>

<session-notification-

policy>com.example.CustomSessionNotificationPolicy</session-notification-policy>

</replication-config>

</jboss-web>

element determines when the container should consider that session data must be replicated

across the cluster. T he 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 and needs to be replicated. This element has 3 valid values:

SET _AND_GET is conservative but not optimal (performance-wise): it will always replicate

session data even if its content only been accessed and not modified. T his setting made (a

little) sense in JBoss Enterprise Application Platform 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 JBoss Enterprise Application Platform 5 or JBoss

Enterprise Web Platform 5.

SET _AND_NON_PRIMITIVE_GET is conservative but will only replicate if an object of a non-

primitive type has been accessed (in effect, 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 the data

needs to be replicated. T his 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.

In all cases, calling setAttribute marks the session as needing replication.

Specifies the name of the JBoss Cache configuration that should be used for storing

distributable sessions and replicating them around the cluster. T his element lets web

applications that require different caching characteristics specify the use of separate, differently

configured, JBoss Cache instances. In JBoss Enterprise Application Platform 4 the cache to use

was a server-wide configuration that could not be changed per web application. T he default

value is standard-session-cache. See Section 17.3, “Configure the JBoss Cache instance

used for session state replication” for more details on JBoss Cache configuration for web-tier

clustering.

Specifies whether all replication messages associated with a request will be batched into one

message. This is applicable only if replication-granularity is FIELD. If replication-

field-batch-mode is set to true, fine-grained changes made to objects stored in the session

attribute map will replicate only when the HTT P request is finished; otherwise they replicate as

they occur. Setting this to false is not advised because it increases the number of replication

requests and the chance of session state being out of sync. Default is true.

FIELD Deprecated

The FIELD granularity option is now deprecated as JBoss Cache, which provides this

feature, is to be subsituted by Infinispan (Infinispan does not support this granularity).

<useJK>

Specifies whether the container should assume that a JK-based software load balancer (for

68 Chapter 17. HTTP session state replication