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:

  1. Modify the Session Manager properties to switch from single to multirow 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:

    1. Determine which data source configuration the Session Manager 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. 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.

Go to previous article: Securing sessions Go to next article: Tuning session support

 

 
Go to previous article: Securing sessions Go to next article: Tuning session support