8.3 Enterprise JavaBeans

---

8.2 Persistent session

By default, WebSphere places session objects in memory. However, the administrator has the option of enabling persistent session management, which instructs WebSphere to place session objects in a persistent store. Administrators should enable persistent session management when:

• The user's session data must be recovered by another cluster member after a cluster member in a cluster fails or is shut down.

• The user's session data is too valuable to lose through unexpected failure at the WebSphere node.

• The administrator desires better control of the session cache memory footprint. By sending cache overflow to a persistent session store, the administrator controls the number of sessions allowed in memory at any given time.

There are two ways to configure session persistence in WebSphere V5. In addition to the traditional database persistence, there is a new feature that provides memory-to-memory session state replication using WebSphere internal messaging; see Figure 8-9 on page 312.

Figure 8-9: Persistent session options

The memory-to-memory session state replication is a new feature of WebSphere Application Server V5 that enables sessions to be shared among application servers without using a database. Using this method, sessions are stored in the memory of an application server, providing the same functionality as a database for session persistence. Separate threads handle this functionality within an existing application server process.

Note 

The internal messaging system is not associated with the embedded WebSphere JMS provider. Instead the code is provided as part of the core WebSphere Application Server libraries. As such, the JMS Server does not need to be started.

All information stored in a persistent session store must be serialized (that is, implement the java.io.Serializable interface). As a result, all of the objects held by a session must implement java.io.Serializable if the session needs to be stored in a persistent session store.

In general, consider making all objects held by a session serialized, even if immediate plans do not call for the use of persistent session management. If the Web site grows, and persistent session management becomes necessary, the transition between local and persistent management occurs transparently to the application if the sessions only hold serialized objects. If not, a switch to persistent session management requires coding changes to make the session contents serialized.

However, the HttpSession can also contain the following J2EE objects, which are not serializable:

• javax.ejb.EJBObject

• javax.ejb.EJBHome

• javax.naming.Context

• javax.transaction.UserTransaction

The WebSphere session manager works around the problem of serializing these objects.

Persistent session management does not impact the session API, and Web applications require no API changes to support persistent session management. However, as mentioned above, applications storing un-serializable objects in their sessions require modification before switching to persistent session management.

If database persistence is used, using multi-row sessions becomes important if the size of the session object exceeds the size for a row, as permitted by the WebSphere session manager. If the administrator requests multi-row session support, the WebSphere session manager breaks the session data across multiple rows as needed. This allows WebSphere to support large session objects. Also, this provides a more efficient mechanism for storing and retrieving session contents under certain circumstances. See "Single vs. multi-row schemas in database persistence" on page 322. Using a cache lets the session manager maintain a cache of most recently used sessions in memory. Retrieving a user session from the cache eliminates a more expensive retrieval from the persistent store. The session manager uses a "least recently used" scheme for removing objects from the cache. Session data is stored to the persistent store based on the write frequency and write option selected.

In this section, we only discuss the session database persistence using DB2 UDB V8 in detail.

8.2.1 Enable database persistence

Before enabling database persistence from the WebSphere V5 administration console, the following tasks should be done:

• Create a session database in the DB2 server to store session data.

• Create a DB2 non-XA JDBC provider. Instructions refer to Chapter 5, "Operational setup" on page 117.

• Create a data source for the session database. In the following instructions, it is assumed that the data source JNDI name is jdbc/Sessions.

The following steps shows how to enable database persistence at the application server level. In WebSphere V5, session management settings can also be performed at the enterprise application level and the Web application level.

In order to enable database persistence, repeat the following steps for each application server.

1. Click Servers -> Application Servers.

2. Select the server.

3. Click Web Container in the Additional Properties table.

4. Click Session Management.

5. Click Distributed Environment Settings.

6. Select Database and click Database.

7. Enter the database information:

   • Enter the data source JNDI name.

   • Enter the user ID and password to be used to access the database. You will need to confirm the password.

   • If you are using DB2 and you anticipate requiring row sizes greater than 4 KB, select the appropriate value from the DB2 row size pull-down.

   • If the DB2 row size is other than 4 KB, you are required to enter the name of tablespace.

   
   Figure 8-10: Session database settings

8. Click OK.

After you have updated each server, save the configuration changes, synchronize them with the servers, and restart the application servers.

8.2.2 Session management tuning

Performance tuning for session management consists of defining the following:

• How often session data is written (write frequency settings)

• How much data is written (write contents settings)

• When the invalid sessions are cleaned up (session cleanup settings)

Write frequency settings

You can select from three different settings that determine how often session data is written to the persistent data store:

• End of servlet service: If the session data has changed, it will be written to the persistent store after the servlet finishes processing an HTTP request.

• Manual update: The session data will be written to the persistent store when the sync() method is called on the IBMSession object.

• Time-based: The session data will be written to the persistent store based on the specified write interval value.

Note 

The last access time attribute is updated each time the session is accessed by the servlet or JSP, whether the session is changed or not. This is done to make sure the session does not time out.

• If you choose the end of servlet service option, each servlet or JSP access will result in a corresponding persistent store update of the last access time.

• If you select the manual update option, the update of the last access time in persistent store occurs on sync() call or at later time.

• If you use time-based updates, the changes are accumulated and written in a single transaction. This can significantly reduce the amount of I/O to the persistent store.

Let us consider an example where the Web browser accesses the application once every 10 seconds:

• In End of servlet service mode, the session would get written out every 10 seconds.

• In Manual update mode, the session gets written out whenever the servlet issues IBMSession.sync(). It is the responsibility of the servlet writer to use the IBMSession interface instead of the HttpSession Interface and the servlets/JSPs must be updated to issue the sync().

• In Time-based mode, the servlet or JSP need not use the IBMSession class nor issue IBMSession.sync(). If the write interval is set to 120 seconds, then the session data gets written out at most every 120 seconds.

End of servlet service

When the write frequency is set to the end of servlet service option, WebSphere writes the session data to the persistent store at the completion of the HttpServlet.service() method call. Exactly what is written depends on the write content settings.

Manual update

In manual update mode, the session manager only sends changes to the persistent data store if the application explicitly requests a save of the session information.

Manual update mode requires that an application developer use the IBMSession class for managing sessions. When the application invokes the sync() method, the session manager writes the modified session data and last access time to the persistent store. The session data that is written out to the persistent store is controlled by the write contents option selected. Example 8-4 is a sample code.

Example 8-4: Use IBMSession to hold the session information

 public void service (HttpServletRequest req, HttpServletResponse res)    throws ServletException, IOException {    // Use the IBMSession to hold the session information    // We need the IBMSession object because it has the manual update    // method sync()    com.ibm.websphere.servlet.session.IBMSession session =    (com.ibm.websphere.servlet.session.IBMSession)req.getSession(true);    Integer value = 1;    //Update the in-memory session stored in the cache    session.putValue("MyManualCount.COUNTER", value);    //The servlet saves the session to the persistent store    session.sync(); } 

If the servlet or JSP terminates without invoking the sync() method, the session manager saves the contents of the session object into the session cache (if caching is enabled), but does not update the modified session data in the session database. The session manager will only update the last access time in the persistent store asynchronously, at a later time.

Note 

Manual updates use an IBM extension to HttpSession that is not part of the Servlet 2.3 API.

This interface gives the Web application developer additional control of when (and if) session objects go to the persistent data store. If the application does not invoke the sync() method, and manual update mode is specified, the session updates goes only to the local session cache, not the persistent data store. Web developers use this interface to reduce unnecessary writes to the session database, and thereby to improve overall application performance.

All servlets in the Web application server must perform their own session management in manual update mode.

Time-based writes to the session database

Using the time-based write option will write session data to the persistent store at a defined write interval. The reasons for implementing time-based write lies in the changes introduced with the Servlet 2.2 API. The Servlet 2.2 specification introduced two key concepts:

• It limits the scope of a session to a single Web application.

• It both explicitly prohibits concurrent access to an HttpSession from separate Web applications but allows for concurrent access within a given JVM.

Because of these changes, WebSphere provides the session affinity mechanism that assures us that an HTTP request is routed to the Web application handling its HttpSession. This assurance still holds in a WLM environment when using persistent HttpSessions. This means that the necessity to immediately write the session data to the persistent store can now be relaxed somewhat in these environments (as well as non-clustered environments), since the persistent store is now really only used for failover and session cache full scenarios.

With this in mind, it is now possible to gain potential performance improvements by reducing the frequency of persistent store writes.

Time-based writes requires session affinity for session data integrity.

The following details apply to time-based writes:

• The expiration of the write interval does not necessitate a write to the persistent store unless the session has been touched (that is, getAttribute/setAttribute/removeAttribute was called) since the last write.

• If a session write interval has expired and the session has only been retrieved (that is, request.getSession() was called since the last write) then the last access time will be written to the persistent store regardless of the write contents setting.

• If a session write interval has expired and the session properties have been either accessed or modified since the last write then the session properties will be written out in addition to the last access time. Which session properties get written out is dependent on the write contents settings.

• Time-based write allows the servlet or JSP to issue IBMSession.sync() to force the write of session data to the database.

• If the time between session servlet requests (for a particular session) is greater than the write interval, then the session effectively gets written out after each service method invocation.

• The session cache should be large enough to hold all of the active sessions. Failure to do this will result in extra persistent store writes, since the receipt of a new session request may result in writing out the oldest cached session to the persistent store. Or to put it another way, if the session manager has to remove the least recently used HttpSession from the cache during a full cache scenario, the session manager will write out that HttpSession (per the Write contents settings) upon removal from the cache.

• The session invalidation time must be at least twice the write interval to ensure that a session does not inadvertently get invalidated prior to getting written to the persistent store.

• A newly created session will always get written to the persistent store at the end of the service method.

Write content settings

These options control what is written. Please refer to "What is written to the persistent session database" on page 324 before selecting one of the options, since there are several factors to take into account. The options available are:

• Only update attributes: Only updated attributes are written to the persistent store.

• All session attributes: All attribute are written to the persistent store.

Session cleanup settings

WebSphere allows the administrator to defer to off hours the clearing of invalidated sessions (sessions that are no longer in use and timed out) from the persistent store. For more information see "Invalidating sessions" on page 327. This can be done either once or twice a day. The fields available are:

• First time of day (0–23): The first hour during which the invalidated persistent sessions will be cleared from the persistent store. This value must be a positive integer between 0 and 23.

• Second time of day (0–23): The second hour during which the invalidated persistent sessions will be cleared from the persistent store. This value must be a positive integer between 0 and 23.

• The property, Specify distributed sessions cleanup schedule, is required to be selected to enable this option.

• Also consider using schedule invalidation for intranet-style applications that have a somewhat fixed number of users wanting the same HTTP session for the whole business day.

The property, Specify distributed sessions cleanup schedule, is required to be selected to enable this option.

Also consider using schedule invalidation for intranet-style applications that have a somewhat fixed number of users wanting the same HTTP session for the whole business day.

Configuration

The session management tuning parameters can be set by selecting a pre-defined tuning level or by specifically specifying each parameter. To specify the performance settings for session management:

1. Select Servers -> Application Servers and click the application server.

2. Click Web Container.

3. Click Session Management.

4. Click Distributed Environment Settings.

5. Select from the predefined tuning levels or click Custom Tuning Parameters. A screen, as shown in Figure 8-11, will be presented.

   
   Figure 8-11: Session management tuning levels

If you want to set each tuning parameter explicitly, select Custom Settings. Figure 8-12 is the screen for setting the parameter.

Figure 8-12: Session management tuning parameters

8.2.3 Using larger DB2 page size for database persistence

WebSphere persistent session supports 4 KB, 8 KB, 16 KB, and 32 KB DB2 page sizes, and hence can have larger varchar for bit data columns of 8K B, 16 KB, or 32 KB. Using this performance feature, we see faster persistence for HttpSession of sizes of 4 KB to 31 KB.

To enable this feature, we must perform the following steps:

1. Create a new DB2 UDB buffer pool that supports the desired page size.

2. Create a table space with which the newly created buffer pool is associated.

3. Select the desired page size from the WebSphere Application Server's Session Manager (DB2 row size).

4. Type in the new table space name in the WebSphere Application Server's Session Manager (Table space name).

5. If the SESSIONS table already exists, drop it from the DB2 database:

    DB2 connect to session DB2 drop table sessions 

6. Create a new DB2 buffer pool and tablespace, specifying the same page size (8 KB, 16 KB or 32 KB) for both, and assign the new buffer pool to this tablespace. The following are simple steps for creating an 8 KB page:

    DB2 connect to session DB2 CREATE BUFFERPOOL sessionBP SIZE 1000 PAGESIZE 8K DB2 connect reset DB2 connect to session DB2 CREATE TABLESPACE sessionTS PAGESIZE 8K MANAGED BY SYSTEM USING ('C:\DB2\NODE0000\SQL00005\sessionTS.0') BUFFERPOOL sessionBP DB2 connect reset 

7. Configure the correct tablespace name and page size (DB2 row size) in the session management database configuration (Figure 8-10 on page 315). Restart WebSphere. On startup, the session manager creates a new SESSIONS table based on the page size and tablespace name specified.

8.2.4 Single vs. multi-row schemas in database persistence

When using the single-row schema, each user session maps to a single database row. This is WebSphere's default configuration for persistent session management. With this setup, there are hard limits to the amount of user-defined, application-specific data that WebSphere Application Server can access.

When using the multi-row schema, each user session maps to multiple database rows. In a multi-row schema, each session attribute maps to a database row. In addition to allowing larger session records, using a multi-row schema can yield performance benefits in certain usage scenarios, such as when larger amounts of data are stored in the session but only small amounts are specifically accessed during a given servlet processing of an HTTP request. In such a scenario, reducing both data retrieved and the serialization overhead for data the application does not use is beneficial to performance.

It should be stressed that switching between multi-row and single-row is not a trivial proposition.

Switching from single-row to multi-row schema

To switch from single-row to multi-row schema for sessions:

1. Modify the session manager properties to switch from single to multi-row schema. You need to select the Use Multi row schema on the Database setting of the Session Manager window, shown in Figure 8-10 on page 315.

2. Manually drop the database table or delete all the rows in the session database table.

   To drop the table:

   1. Determine which data source the session manager is using. This is set in the session management distributed settings window. See "Enable database persistence" on page 313.

   2. Look up the database name in the data source settings. You will need to find the JDBC provider, then the data source. The database name is in the custom settings.

   3. Use the database facilities to connect to the database and drop it.

3. Restart the application server or cluster.

To verify which option is better for your application's needs, you can configure single-row usage to one database and multi-row usage to another database. Then you monitor the performance by switching the data source.

Table 8-1: Single vs. multi-row schemas

Programming issue	Application scenario
Reasons to use single-row	You can read/write all values with just one record read/write. This takes up less space in a database, because you are guaranteed that each session is only one record long.
Reasons not to use single-row	2 MB limit of stored data per session; that is, the sum of sizes of all session attributes is limited to 2 MB.
Reasons to use multi-row	The application can store an unlimited amount of data; that is, you are limited only by the size of the database and a 2 MB-per-record limit (so the size of each session attribute can be 2 MB). The application can read individual fields instead of the whole record. When large amounts of data are stored in the session but only small amounts are specifically accessed during a given servlet's processing of an HTTP request, multi-row sessions can improve performance by avoiding unneeded Java object serialization.
Reasons not to use multi-row	If data is small in size, you probably do not want the extra overhead of multiple row reads when everything could be stored in one row.

8.2.5 What is written to the persistent session database

WebSphere supports two modes for writing session contents to the persistent store:

• Only updated attributes. Write only the HttpSession properties that have been updated via setAttribute() and removeAttribute().

• All session attributes. Write all the HttpSession properties to the database.

When a new session is initially created (with either of the above two options) the entire session is written, including any Java objects bound to the session. When using database persistence, the behavior for subsequent servlet or JSP requests for this session varies depending on whether the single-row or multi-row database mode is in use.

• In single-row mode:

  • Only updated attributes: If any session attribute has been updated (via setAttribute or removeAttribute), then all of the objects bound to the session will be written to the database.

  • All session attributes: All bound session attributes will be written to the database.

• In multi-row mode:

  • Only updated attributes: Only the session attributes that were specified via setAttribute or removeAttribute will be written to the database.

  • All session attributes: All of the session attributes that reside in the cache will be written to the database. If the session has never left the cache, then this should contain all of the session attributes.

By using the All session attributes mode, servlets and JSPs can change Java objects that are attributes of the HttpSession without having to call setAttribute() on the HttpSession for that Java object in order for the changes to be reflected in the database.

Adding the All session attributes mode provides some flexibility to the application programmer and protects against possible side effects of moving from local sessions to persistent sessions.

However, using All session attributes mode can potentially increase activity and be a performance drain. Individual customers will have to evaluate the pros and cons for their installation. It should be noted that the combination of All session attributes mode with time-based write could greatly reduce the performance penalty and essentially give you the best of both worlds.

As shown in Example 8-5 and Example 8-6, the initial session creation contains a setAttribute but subsequent requests for that session do not need to use setAttribute. The initial session creation contains a setAttribute, but subsequent requests for that session do not need to use setAttribute.

Example 8-5: Servlet initially creates a session object

 HttpSession sess = request.getSession(true); myClass myObject = new myClass(); myObject.someInt = 1; sess.setAttribute("myObject", myObject); // Bind object to the session 

Example 8-6: Subsequently modifying the session object

 HttpSession sess = request.getSession(false); myObject = sess.getAttribute("myObject"); // get bound session object myObject.someInt++; // change the session object // setAttribute() not needed with write "All session attributes" specified 

HttpSession set/getAttribute action summary

Table 8-2 on page 326 summarizes the action of the HttpSession setAttribute and removeAttribute methods for various combinations of the row type, write contents, and write frequency session persistence options.

Table 8-2: HttpSession action summary

Row type	Write contents	Write frequency	Action for setAttribute	Action for remove-Attribute
Single-row	Only updated attributes	End of servlet service/sync() call with manual update	If any of the session data has changed, then write all of this session's data from cache.	If any of the session data has changed, then write all of this session's data from cache.
Single-row	Only updated attributes	Time-based	If any of the session data has changed, then write all of this session's data from cache.	If any of the session data has changed, then write all of this session's data from cache.
Single-row	All session attributes	End of servlet service/sync() call with manual update	Always write all of this session's data from cache.	Always write all of this session's data from cache.
Single-row	All session attributes	Time-based	Always write all of this session's data from cache.	Always write all of this session's data from cache.
Multi-row	Only updated attributes	End of servlet service/sync() call with manual update	Write only thread-specific data that has changed.	Delete only thread-specific data that has been removed.
Multi-row	Only updated attributes	Time-based	Write thread-specific data that has changed for all threads using this session.	Delete thread-specific data that has been removed for all threads using this session.
Multi-row	All session attributes	End of servlet service/sync() call with manual update	Write all session data from cache.	Delete thread-specific data that has been removed for all threads using this session.
Multi-row	All session attributes	Time-based	Write all session data from cache.	Delete thread-specific data that has been removed for all threads using this session.

Multi-row mode has the notion of thread-specific data. Thread-specific data is defined as session data that was added or removed while executing under this thread. If End of servlet service or Manual update modes are used and Only updated attributes is enabled, then only the thread-specific data is written to the database.

8.2.6 Invalidating sessions

Sessions should be invalidated when the user no longer needs the session object (for example, the user has logged off the site). Invalidating a session removes it from the session cache, as well as from the persistent store.

WebSphere offers three methods for invalidation session objects:

• Programmatically, by calling the invalidate() method on the session object. If the session object is accessed by multiple threads in a Web application, take care that none of the threads still have references to the session object.

• An invalidator thread scans for timed-out sessions every n seconds, where n is configurable from the administrative console. The session timeout setting is found in the session management configuration for the application server Web container.

• For persistent sessions, the administrator can specify times when the scan will be run. This feature has the following benefits when used with persistent session:

  • Persistent store scans can be scheduled during periods that normally have low demand. This avoids slowing down online applications due to contention in the persistent store.

  • When this setting is used with the End of servlet service write frequency option, WebSphere does not have to write out the last access time with every HTTP request. This is because WebSphere does not have to synchronize the invalidator thread's deletion with the HTTP request access.

The session cleanup schedule setting is found in the session management settings for the Web container. You will find it with the custom tuning properties for distributed environments.

8.2.7 Session performance best practices

This section includes some considerations for developing and administering scalable, high-performance Web applications using WebSphere Application Server session support.

Session size

Large session objects pose several problems for a Web application. If the site uses session caching, large sessions reduce the memory available in the WebSphere instance for other tasks, such as application execution.

For a database persistent session using DB2, if session objects are larger than 32 k (see "Using larger DB2 page size for database persistence" on page 321), then the data are not cached in DB2 buffer pool. This will have an impact on the session performance. For example, assume that a given application stores 1 MB of information per user session object. If 100 users arrive over the course of 30 minutes, and assume the session timeout remains at 30 minutes, the application server instance must allocate 100 MB just to accommodate the newly arrived users in the session cache. Note that this number does not include previously allocated sessions that have not timed out yet. The actual memory required by the session cache could be considerably higher than 100 MB.

 1 MB per user session * 100 users = 100 MB 

Web developers and administrators have several options for improving the performance of session management:

• Reduce the size of the session object.

• Configure the size of the session cache.

• Add additional instances.

• Invalidate unneeded sessions.

• Increase the memory available.

• Reduce the session timeout interval.

Reduce session object size

Web developers/application designers must carefully consider the information kept by the session object and not make the session objects too large.

Using larger DB2 page size

See "Using larger DB2 page size for database persistence" on page 321 to find out how WebSphere V5 can provide faster persistence of larger session objects when using DB2.

Session cache size

The session manager allows administrators to change the session cache size to alter the cache's memory footprint. By default, the session cache holds 1000 session objects. By lowering the number of session objects in the cache, the administrator reduces the memory required by the cache.

However, if the user's session is not in the cache, WebSphere must retrieve it from either the overflow cache (for local caching) or the session database (for persistent sessions). If the session manager must retrieve persistent sessions frequently, the retrievals may impact overall application performance.

Create additional application server instances

WebSphere also gives the administrator the option of creating additional application server instances. Creating additional instances spreads the demand for memory across more JVMs, thus reducing the memory burden on any particular instance. Depending on the memory and CPU capacity of the machines involved, the administrator may add additional instances within the same machine. Alternatively, the administrator may add additional machines to form a hardware cluster, and spread the instances across this cluster.

Invalidate unneeded sessions

If the user no longer needs the session object, for example, when the user has logged out of the site, it should be invalidated. Invalidating a session removes it from the session cache, as well as from the session database. For more information see "Invalidating sessions" on page 327.

Increase available memory

WebSphere allows the administrator to increase an application server's heap size. By default, WebSphere allocates 256 MB as the maximum heap size.

Increasing this value allows the instance to obtain more memory from the system, and thus hold a larger session cache.

Session timeout interval

By default, each user receives a 30-minute interval between requests before the session manager invalidates the user's session. Not every site requires a session timeout interval this generous. By reducing this interval to match the requirements of the average site user, the session manager purges the session from the cache (and the persistent store, if enabled) more quickly.

Avoid setting this parameter too low and frustrating users. The administrator must take into account a reasonable time for an average user to interact with the site (read returned data, fill out forms, and so on) when setting the interval. Also, the interval must represent any increased response time during peak times on the site (such as heavy trading days on a brokerage site, for example).

In some cases where the persistent store contains a large number of session entries, frequent execution of the timeout scanner reduces overall performance. In these cases, avoid setting the session timeout so low it triggers frequent, expensive scans of the persistent store for timed-out sessions. Alternatively, the schedule-based invalidation should be considered where scans for invalid object can be deferred to a time that normally has low demand. See "Invalidating sessions" on page 327 for more information.

Consider using multi-row session in database persistence

When a session contains multiple objects accessed by different servlets or JSPs in the same Web application, multi-row session support provides a mechanism for improving performance. See "Single vs. multi-row schemas in database persistence" on page 322 for more information.

Even with multi-row session support, WebSphere applications perform best if the overall contents of the session objects remain small. Large values in session objects require more time to retrieve from the persistent session database, generate more network traffic in transit, and occupy more space in the session cache after retrieval.

Multi-row session support provides a good compromise for Web applications requiring larger sessions. However, single-row persistent session management remains the best choice for Web applications with small session objects. Single-row persistent session management requires less storage in the database, and requires fewer database interactions to retrieve a session's contents (all of the values in the session are written or read in one operation). This keeps the session object's memory footprint small, as well as reduces the network traffic between WebSphere and the persistent session database.

Managing your session database connection pool

When using persistent session management, the session manager interacts with the defined database through a WebSphere Application Server data source. Each data source controls a set of database connections known as a connection pool. By default, the data source opens a pool of no more than 10 connections. The maximum pool size represents the number of simultaneous accesses to the persistent session database available to the session manager.

For high-volume Web sites, the default settings for the persistent session data source may not be sufficient. If the number of concurrent session database accesses exceeds the connection pool size, the data source queues the excess requests until a connection becomes available. Data source queueing can impact the overall performance of the Web application (sometimes dramatically).

See "Tuning WebSphere DataSources" on page 303 to find how to tune the connection pool.

Session database tuning

While the session manager implementation in WebSphere provides for a number of parameters that can be tuned to improve performance of applications that utilize HTTP sessions, maximizing performance will require tuning the underlying session persistence table. WebSphere V5 provides a "first step" in this regard by creating an index for the sessions table when creating the table. The index is comprised of the session ID, the property ID (for multi-row sessions), and the Web application name.

While DB2 UDB provides a great deal of capability in tuning at the table or tablespace level, creation of a separate database or instance will afford the most flexibility in tuning. Proper tuning of the instance/database can improve the performance.

While the specifics will vary depending on the database and operating system in use, in general the database should be tuned and configured as appropriate for a database that experiences a great deal of I/O. The DBA should monitor and tune the database buffer pools, database log size, and write frequency. Additionally, maximizing performance will require striping the database/instance across multiple disk drives and disk controllers, and utilizing any hardware or OS buffering that is available in order to reduce disk contention.

---