Controlling write operations

Why and when to perform this task

You can manually control when modified session data is written out to the database or to another WebSphere Application Server instance by using the sync method in the com.ibm.websphere.servlet.session.IBMSession interface, which extends the javax.servlet.http.HttpSession interface. By calling the sync method from the service method of a servlet, you send any changes in the session to the external location. When manual updateis selected as the write frequency mode, session data changes are written to an external location only if the application calls the sync method. If the sync method is not called, session data changes are lost when a session object leaves the server cache. When end of service servlet or time based is the write frequency mode, the session data changes are written out whenever the sync method is called. If the sync method is not called, changes are written out at the end of service method or on a time interval basis based on the write frequency mode selected.

   IBMSession iSession = (IBMSession) request.getSession();
   iSession.setAttribute("name", "Bob");
   
   //force write to external store
   iSession.sync( )

If the database is down or is having difficulty connecting during an update to session values, the sync method always makes 3 attempts before it finally throws an "BackedHashtable.getConnectionError" error. For each connection attempt that fails, the "BackedHashtable.StaleConnectionException" is thrown and can be found in the sync method. If the database comes up during any of these three attempts, the session data in the memory is then persisted and committed to the database.

However, if the database is still not up after the three attempts, then the session data in the memory is persisted only after the next check for session invalidation. Session invalidation is checked by a separate thread that is triggered every five minutes. The data in memory is consistent unless a request for session data is issued to the server between these events. For example, if the request for session data is issued within five minutes, then the previous persisted session data is sent.

Sessions are not transactional resources. Because the sync method is associated with a separate thread than the client, the exception thrown does not propagate to the client, which is running on the primary thread. Transactional integrity of data can be maintained through resources such as enterprise Java beans.


Related reference
Tuning session management



Searchable topic ID:   tprs_pers
Last updated: Jun 21, 2007 4:55:42 PM CDT    WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprs_pers.html

Library | Support | Terms of Use | Feedback