Multirow schema
Overview
With the multirow schema option each piece of application specific data is stored in a separate row of the database. Doing this avoids unneeded Java object serialization when large amounts of data are stored in the session but, only small amounts are being processed.
Coding considerations and test environment
Programming issue Application scenario Reasons to use single-row You can read or write all values with just one record read and 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 multirow 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 servlet processing of an HTTP request, multirow sessions can improve performance by avoiding unneeded Java object serialization.
Reasons not to use multirow If data is small in size, you probably do not want the extra overhead of multiple row reads when you can store everything in one row.
In the case of multirow 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 multirow 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.
Switching to a multirow 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.
- Modify the Session Management facility properties to switch from single to multirow schema.
- 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:
- Determine which data source configuration Session Management is using.
- In the data source configuration, look up the database name.
- Use the database facilities to connect to the database.
- Drop the SESSIONS table.
See Also