InfoCenter Home >
4: Developing applications >
4.4: Personalizing applications >
4.4.1: Tracking sessions >
4.4.1.1: Session programming model and environment >
4.4.1.1.4: Deciding between single-row and multirow schema for sessions
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.
|
|