Multi-row schema

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 WAS can access.

WAS supports the use of a multi-row schema option in which each piece of application specific data is stored in a separate row of the database. With this setup, the total amount that can be placed in a session is now bound only by the database capacities. The only practical limit that remains is the size of a session attribute object itself.

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's processing of a http request. In such a scenario, avoiding unneeded Java object serialization is beneficial to performance.

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

Deciding between single-row and multi-row schema for sessions

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

Switching from single-row to multi-row schema

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

1. On the (Session Management) Database Properties page in the administrative console, select Use Multi row schema to switch from single to multi-row schema.
2. Manually drop the database table or delete all the rows in the database table that the product uses to maintain HttpSession objects. To drop the table, perform these steps:
   1. Determine which data source configuration the Session Manager is using.
   2. In the data source configuration, look up the database name. If the database name is listed as *LOCAL, then the Session Manager uses the default collection, QEJBAS5SN, for persisting session data.
   3. Use the database facilities to connect to the database.
   4. Drop the SESSIONS table.

Coding considerations and test environment

Consider configuring direct single-row usage to one database and multi-row usage to another database while you verify which option suits your application's specific needs. (Do this in code by switching the datasource used; then monitor performance.)

Reasons to use single-row:

• You can read or 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-megabyte limit of stored data per session.

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-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 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.

In the case of multi-row usage, design your application data objects not to have references to each other, to prevent circular references. For example, suppose you 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.