This preview shows page 336 - 338 out of 446 pages.
environments (as well as non-clustered environments), since the persistent store is now really only used for failover and session cache full scenarios.With this in mind, it is now possible to gain potential performance improvements by reducing the frequency of persistent store writes.Time-based writes requires session affinity for session data integrity.The following details apply to time-based writes:The expiration of the write interval does not necessitate a write to the persistent store unless the session has been touched (that is, getAttribute/setAttribute/removeAttribute was called) since the last write.If a session write interval has expired and the session has only been retrieved (that is, request.getSession() was called since the last write) then the last access time will be written to the persistent store regardless of the write contents setting.If a session write interval has expired and the session properties have been either accessed or modified since the last write then the session properties will be written out in addition to the last access time. Which session properties get written out is dependent on the write contents settings.Time-based write allows the servlet or JSP to issue IBMSession.sync() to force the write of session data to the database.If the time between session servlet requests (for a particular session) is greater than the write interval, then the session effectively gets written out after each service method invocation.The session cache should be large enough to hold all of the active sessions. Failure to do this will result in extra persistent store writes, since the receipt of a new session request may result in writing out the oldest cached session to
Chapter 8. DB2 UDB V8 and WAS V5 integrated performance 319the persistent store. Or to put it another way, if the session manager has to remove the least recently used HttpSession from the cache during a full cache scenario, the session manager will write out that HttpSession (per the Write contents settings) upon removal from the cache.The session invalidation time must be at least twice the write interval to ensure that a session does not inadvertently get invalidated prior to getting written to the persistent store.A newly created session will always get written to the persistent store at the end of the service method.Write content settingsThese options control what is written. Please refer to “What is written to the persistent session database” on page 324 before selecting one of the options, since there are several factors to take into account. The options available are:Only update attributes: Only updated attributes are written to the persistent store.All session attributes: All attribute are written to the persistent store.