4.4.1.1.4: Deciding between single-row and multirow schema for sessions
Using the single-row schema,
each user session maps to a single database row.
Using the multirow schema,
each user session maps to multiple database rows.
(In a multirow schema,
each session attribute maps to a database row.)
In addition to allowing larger session records, using multirow schema
can yield performance benefits, as discussed in
article 4.4.1.1.7.3.
However, it
requires a little work to switch to from single-row to multirow schema, as
shown in the instructions below.
Switching from single-row to multirow schema
To switch from single-row to multirow schema for sessions:
Modify the Session Manager 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 the Session Manager 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.
Restart the Session Manager.
Coding considerations and test environment
Consider configuring direct single-row usage
to one database and multirow 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.)
Programming issue
Application scenario
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 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 a given servlet's 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 everything could be stored 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(..) , 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 retreived later, the object graph between A and B is
different than stored. A and B behave as independent objects.