To ensure highly available web applications with persistent session data, the
high availability database (HADB) provides a backend store to save HTTP session data.
However, there is a overhead involved in saving and reading the data back from HADB.
Understanding the different schemes of session persistence and their impact on performance
and availability will help you make decisions in configuring Application Server for high
availability.

In general, maintain twice as many HADB nodes as there are application server
instances. Every application server instance requires two HADB nodes.

Tuning Session Persistence Frequency

The Application Server provides HTTP session persistence and failover by writing
session data to HADB. You can control the frequency at which the server writes to
HADB by specifying the persistence frequency.

All else being equal, time-based persistence frequency provides better performance
but less availability than web-method persistence frequency. This is because the session
state is written to the persistent store (HADB) at the time interval specified by
the reap interval (default is 60 seconds). If the server instance fails within that
interval, the session state will lose any updates since the last time the session
information was written to HADB.

Web-method

With web-method persistence frequency, the server writes the HTTP session state
to HADB before it responds to each client request. This can have an impact on response
time that depends on the size of the data being persisted. Use this mode of persistence
frequency for applications where availability is critical and some performance degradation
is acceptable.

Time-based

With time-based persistence frequency, the server stores session information
to the persistence store at a constant interval, called the reap interval. You specify the reap interval under Configurations > config-name > Web Container (Manager Properties), where config-name is
the name of the configuration. By default, the reap interval is 60 seconds. Every
time the reap interval elapses, a special thread “wakes up,” iterates
over all the sessions in memory, and saves the session data.

In general, time-based persistence frequency will yield better performance than
web-method, since the server’s responses to clients are not held back by saving
session information to the HADB. Use this mode of persistence frequency when performance
is more important than availability.

Session Persistence Scope

You can specify the scope of the persistence in addition to persistence frequency
on the same page in the Admin Console where you specify persistence frequency, Configurations
> config-name > Availability Service (Web Container Availability).

session

With the session persistence scope, the server writes the entire session data
to HADB—regardless of whether it has been modified. This mode ensures that the
session data in the backend store is always current, but it degrades performance,
since all the session data is persisted for every request.

modified-session

With the modified-session persistence scope, the server examines the state of
the HTTP session. If and only if the data has been modified, the server saves the
session data to HADB. This mode yields better performance than session mode, because
calls to HADB to persist data occur only when the session is modified.

modified-attribute

With the modified-attribute persistence scope, there are no cross-references
for the attributes, and the application uses setAttribute() and getAttribute() to manipulate HTTP session data. Applications written this
way can take advantage of this session scope behavior to obtain better performance.

Session Size

It is critical to be aware of the impact of HTTP session size on performance. Performance
has an inverse relationship with the size of the session data that needs to be persisted.
Session data is stored in HADB in a serialized manner. There is an overhead in serializing
the data and inserting it as a BLOB and also deserializing it for retrieval.

Tests have shown that for a session size up to 24KB, performance remains unchanged.
When the session size exceeds 100KB, and the same back-end store is used for the same
number of connections, throughput drops by 90%.

It is important to pay attention while determining the HTTP session size. If
you are creating large HTTP session objects, calculate the HADB nodes as discussed
in Tuning HADB.

Checkpointing Stateful Session Beans

Checkpointing saves a stateful session
bean (SFSB) state to the HADB so that if the server instance fails, the SFSB is failed
over to another instance in the cluster and the bean state recovered. The size of
the data being checkpointed and the frequency at which checkpointing happens determine
the additional overhead in response time for a given client interaction.

You can enable SFSB checkpointing at numerous different levels:

For the entire server instance or EJB container

For the entire application

For a specific EJB module

Per method in an individual EJB module

For best performance,
specify checkpointing only for methods that alter the bean state significantly, by
adding the <checkpointed-methods> tag in the sun-ejb-jar.xml file.

Initial and Minimum Pool Size:
Minimum and initial number of connections maintained in the pool (default is 8)

Maximum Pool Size: Maximum number
of connections that can be created to satisfy client requests (default is 32)

Pool Resize Quantity: Number of
connections to be removed when idle timeout timer expires

Idle Timeout: Maximum time (seconds)
that a connection can remain idle in the pool. (default is 300)

Max Wait Time: Amount of time (milliseconds)
caller waits before connection timeout is sent

For optimal performance, use a pool with eight to 16 connections per node. For
example, if you have four nodes configured, then the steady-pool size must be set
to 32 and the maximum pool size must be 64. Adjust the Idle Timeout and Pool Resize
Quantity values based on monitoring statistics.

For the best performance, use the following settings:

Connection Validation: Required

Validation Method: metadata

Transaction Isolation Level: repeatable-read

In addition to the standard attributes, add the two following properties:

cacheDatabaseMetaData: false

eliminateRedundantEndTransaction: true

To add a property, click the Add Property button, then specify the property
name and value, and click Save.