Write contents

In Session Manager, you can configure which session data is written to the database. This flexibility allows for fewer code changes for the JSP writer when the application operates in a distributed environment.

The following options are available in Session Manager for tuning what is to be written back to the database:

The Write all setting might benefit servlet and JSP writers who change Java objects that reside as attributes in an HttpSession instance. Previously, every programmatic change in an attribute would require a setAttribute() call to make sure changes were reflected in the database in a timely manner. In most cases, the use of this setting eliminates the need for all but the initial setAttribute() call to bind the object to the session.

However, the use of Write all could result in more being written back to the database than is necessary. If this situation applies to you, consider combining the use of Write all with time-based write to boost overall performance. Be sure to evaluate the advantages and disadvantages for your installation.

With either of the Write contents settings, when a session is first created, complete session information is written to the database. This includes all of the objects bound to the session. In subsequent session requests, what is written to the database depends on whether a single-row or multi-row schema has been set for the session database. The following table shows the behavior of the Write contents settings to both single-row and multi-row schema:

Write contents setting Behavior with single-row schema Behavior with multi-row schema
Only updated attributes If any session attribute is updated, all objects bound to the session are written. Only the session data modified through setAttribute() or removeAttribute() calls is written.
All session attributes All bound session attributes are written. All session attributes that currently reside in the cache are written. If the session has never left the cache, all session attributes are written.