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.7: Tuning session support >
4.4.1.1.7.4: Tuning session support: Write frequency

4.4.1.1.7.4: Tuning session support: Write frequency

In 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:

  • End of service method (the default) - Write session data at the end of the servlet's service() method call.
  • Manual update - Write session data when the servlet calls the IBMSession.sync() method.
  • Time-based write - Write session data every so many seconds (called the write interval).

When a session is first created, session information is always written to the database at the end of the service() call.

End of service method

By 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 update

With 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.

Programming issue Application scenario
Reasons to use manual update
  • You want direct control over when session information is persisted to the database.
  • The servlets of the application typically read in the session data but do not write it back as much.
Reasons not to use manual update
  • You do not want to control persistence of session information by using the IBMSession object, or you prefer that WebSphere explicitly control persistence to the database.
  • The servlets of the application are writing session information frequently.
  • Your code must comply completely with the Servlet 2.2 specification. The sync() method is not part of the Servlet specification; it is an IBM extension.

Time-based write

With 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.

  • If the Write Frequency option is set to End of service method, session information gets written every five seconds.
  • If the Write Frequency option is set to Manual update, session information gets written whenever the application code calls IBMSession.sync().
  • If the Write Frequency option is set to Time based write and the write interval is set to 120 seconds, session information gets written no more frequently than every 120 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.

Go to previous article: Tuning session support: Multirow schema Go to next article: Tuning session support: Base in-memory session pool size

 

 
Go to previous article: Tuning session support: Multirow schema Go to next article: Tuning session support: Base in-memory session pool size