Switching to a multi-row schema

The multi-row schema configuration supports storing an unlimited amount of data that is only bounded by the database capacities in an application. The application can read individual fields instead of the whole record, which can help to improve performance by avoiding unnecessary Java object serialization. Configure the session management facility to store each attribute in a session object in its own row in the database using the multi-row schema configuration.

The only practical limit that remains is the size of the session attribute object. The multi-row schema potentially has 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, avoiding unneeded Java object serialization is beneficial to performance.

In addition to allowing larger session records, using multi-row schema can yield performance benefits. However, it requires a little work to switch from single-row to multi-row schema, as shown in the following table.

By default, a single session maps to a single row in the database table used to hold sessions. With this setup, there are hard limits to the amount of user-defined, application-specific data that WebSphere Application Server can access.

Consider configuring direct single-row usage to one database and multi-row usage to another database while you verify which option suits the application needs. Do this in code by switching the data source used; then monitor performance.

Programming issue	Application scenario
Reasons to use single-row	We can read or write all values with just one record read and write. This takes up less space in a database because we are guaranteed that each session is only one record long.
Reasons not to use single-row	2-megabyte limit of stored data per session.
Reasons to use multi-row	The application can store an unlimited amount of data; that is, we are limited only by the size of the database and a 2-megabyte-per-record limit. 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 servlet 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 we can store everything in one row.

In the case of multi-row usage, design the application data objects not to have references to each other, to prevent circular references. For example, suppose we are storing two objects A and B in the session using HttpSession.put(..) method, and A contains a reference to B. In the multi-row case, because objects are stored in different rows of the database, when objects A and B are retrieved later, the object graph between A and B is different than stored. A and B behave as independent objects.

Tasks

1. Modify the Session Management facility properties to switch from single to multi-row schema.
2. Manually drop the table.

   To drop the table:

   1. Determine which data source configuration Session Management is using.

   2. In the data source configuration, look up the database name.

   3. Use the database facilities to connect to the database.
   4. Drop the SESSIONS table.

3. Recreate the database table or delete all the rows in the database table that the product uses to maintain HttpSession objects.

   See the DB2 UDB for OS/390 and z/OS V7 Administration Guide for a description of how to drop a DB2 database table.

   Create a DB2 table for session persistence describes how to create a new DB2 database table.

Session management tuning

Configure for database session persistence