This section discusses how you can configure the high availability features of Enterprise Server. This section discusses the following topics:
Descriptor configuration in the web application
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 Enterprise 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.
The Enterprise 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.
Specify the persistence frequency in the Admin Console under Configurations > config-name > Availability Service (Web Container Availability).
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.
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.
For more information on web-method persistence frequency, see Configuring Availability for the Web Container in Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide.
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.
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).
For detailed description of different persistence scopes, see Chapter 7, Configuring High Availability Session Persistence and Failover, in Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide.
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.
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.
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.
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 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.
Configure the JDBC connection pool in the Admin Console under Resources > JDBC > Connection Pools > pool-name. The connection pool configuration settings are:
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
To add a property, click the Add Property button, then specify the property name and value, and click Save.
For more information on configuring the JDBC connection pool, see Tuning JDBC Connection Pools.