InfoCenter Home > 4.4.1.1.7.4: Tuning session support: Write frequencyIn the Session Manager, you can configure the frequency for writing session data to the database. This flexibility enables you to weigh session performance gains against varying degrees of failover support. The following options are available in Session Manager for tuning write frequency:
When a session is first created, session information is always written to the database at the end of the service() call. End of service methodBy default, IBM WebSphere Application Server updates the database with any changes made to the session during the servlet processing of an HTTP request (for example, during the execution of the service() method). These updates minimally include the last access time of the session and typically also include changes affected by the servlet, such as updating or removing application data. Exactly how much is written back can be configured with the write contents option. Manual updateWith manual updates, the servlet using a session determines when to write session information to the database. Switching to manual updates improves performance when the number of times an HTTP request's processing leads to changing a session (typically its application data) is typically less than the number of times the session is accessed or read in. When manual update is set, the product session support no longer automatically updates the database at the end of a servlet's service() method. (However, when an HttpSession object is first created, session information is written to the database as part of postprocessing for the servlet request in which the session was created.) The last update times are cached and updated asynchronously prior to checks for session invalidation. For any permanent changes to the session as part of servlet processing, the servlet code must specifically call the sync() method of the com.ibm.websphere.servlet.session.IBMSession interface.
Time-based writeWith time-based write, session data is written back to the database every time the write interval expires. Expiration of the write interval does not force a write operation; data is written only if the session has been retrieved or modified. For example, suppose that a web application updates a session object every five seconds.
Using the time based write setting requires that the session invalidation time be at least twice as large as the write interval. This is needed to ensure that a session is not prematurely invalidated. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|