InfoCenter Home >
4: Developing applications >
4.4: Personalizing applications >
4.4.1: Tracking sessions >
4.4.1.1: Session programming model and environment >
4.4.1.1.7: Tuning session support

4.4.1.1.7: Tuning session support

IBM WebSphere Application Server session support has features for tuning session performance and operating characteristics, particularly when sessions are persisted in a database. These options allow the administrator flexibility in determining the performance and failover characteristics for their environment.

The table summarizes the features, including whether they apply to sessions tracked in memory, in a database, or either. Click a feature for details about the feature. Some features are easily manipulated using administrative settings; others require code or database changes.

Feature or option Goal Applies to sessions in memory or database?
Write frequency Minimize database write operations. Database
Multirow schema Fully utilize database capacities. Database
Base in-memory session pool size Fully utilize system capacity without overburdening system. Either
Write contents Allow flexibility in determining what session data to write Database
Scheduled invalidation Minimize contention between session requests and invalidation of sessions by Session Manager. Minimize write operations to database for updates to last access time only. Database
Tablespace and row size Increase efficiency of write operations to database. Database

Using a new system property in a multi-Java virtual machine environment

Session ID can be shared across WebSphere Application Server in a multi-Java virtual machine (JVM) environment without session persistence configured by using a new system property HttpSessionIdReuse.

To apply a new system property, complete these steps :

  1. Under WebSphere Administrative Domain, click Nodes.
  2. Select the node on which the application server is located
  3. Click Application Servers.
  4. Click Default Server.
  5. Click Process Definition.
  6. Click the JVM Settings tab, and and then click System Properties from the right panel under Advanced Settings.
  7. Click New.
  8. Specify Name as HttpSessionIdReuse and Value as true.
  9. Click OK.
  10. Save the configuration.
  11. Restart the application server.

Using the SessionReaperInterval property

SessionReaperInterval is a new system property introduced in 4.0.3. It sets an explicit value for the sleep interval of the Session Invalidation Thread.

To apply the system property on each application server, complete the following:

  1. Under WebSphere Administrative Domain, click Nodes.
  2. Select the node on which the application server is located
  3. Click Application Servers.
  4. Select the appropriate application server, and click the JVM Settings tab, and scroll down.
  5. Click the Add button next to the table titled System Properties, and type the name as SessionReaperInterval and the value in seconds.
  6. Apply the changes.
  7. Restart the application server.

Session sharing across Web applications is not supported on z/OS platform

FixPak 4.0.4 introduces support for sharing HTTP session data among Web applications that are packaged in the same Java 2 Platform, Enterprise Edition (J2EE) application. This feature is a value-add extension provided by WebSphere Application Server to the behavior that is prescribed by the servlet V2.2 specification. Currently, the feature is exclusive to WebSphere Application Server for multi-platforms. It is not currently supported on WebSphere Application Server for z/OS. Applications that take advantage of this extended feature cannot deploy to WebSphere Application Server for z/OS.

Managing locking behavior an HTTP session

There are three Java system properties that manage locking behavior. Set these properties with the Java -D<system property=value> parameter on the command line option of an application server:

syncOnHttpSession
Indicates whether or not to turn on the locking behavior. Set this option to any non-null value to turn on this behavior.
syncOnHttpSessionTO
Indicates the amount of time a servlet request waits on an HTTP session before continuing execution. This parameter is optional and expressed in seconds. The default is 120000, or 2 minutes. Under normal conditions, a servlet request waiting for access to an HTTP session gets notified by the request that currently owns the given HTTP session when the request finishes.
syncOnHttpSessionFailOnTO
Determines if the request executes the servlet, or aborts servlet execution in the event of a timeout, creating error logs. This parameter is optional and expressed as the boolean true or false. If the value is false, multiple servlet requests that have timed out concurrently, execute concurrently. The default value is true, servlet execution aborts.

Using Java Transaction API for persisting sessions

The Java Transaction API (JTA)-enabled data source for the Session Persistence database is not supported.

Adding a system property to ensure session object is latest

The verifyDatabaseCopy system property can ensures that the session object in cache is in synch with the session object persisted to the database. This is in addition to the cache ID mechanism used for the same purpose.

To apply this property, follow these steps :

  1. From the administrative console, click Command Line Arguments for the application server, and then specify -DverifyDatabaseCopy=true. By default this property is set to false.
  2. Restart the application server.
Go to previous article: Deciding between single-row and multirow schema for sessions Go to next article: Tuning session support: Session persistence

 

 
Go to previous article: Deciding between single-row and multirow schema for sessions Go to next article: Tuning session support: Session persistence