In session management, you can configure which session data is written to the database or to another WebSphere instance, depending on whether you are using database persistent sessions or memory to memory replication. This flexibility allows for fewer code changes for the JavaServer Pages (JSP) writer when the application will be operating in a clustered environment. The following options are available in Session Management for tuning what is to be written back:
The Write all setting might benefit servlet and JSP writers who change Java objects' states that reside as attributes in HttpSession and do not call HttpSession.setAttribute method.
However, the use of Write all could result in more data being written back than is necessary. If this situation applies to you, consider combining the use of Write all with Time-based write to boost performance overall. As always, be sure to evaluate the advantages and disadvantages for your installation.
With either Write Contents setting, when a session is first created, complete session information is written, including all of the objects bound to the session. When using database session persistence, 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, as follows:
Write Contents setting | Behavior with single-row schema | Behavior with multirow schema |
---|---|---|
Write changed | If any session attribute is updated, all objects bound to the session are written. | Only the session data modified through setAttribute method or removeAttribute method calls is written. |
Write all | 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. |
Related reference
Session management tuning
Searchable topic ID: tprs_rtcn