Network Deployment (Distributed operating systems), v8.0 > Applications > Web applications > Sessions
Write operations
We can manually control when modified session data is written out to the database or to another WAS instance by using the sync method in the com.ibm.websphere.servlet.session.IBMSession interface. The manual update, end of service servlet and the time based write frequency modes are available to tune write frequency of session data.
This interface extends the javax.servlet.//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/ .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 update is 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 that is selected.
IBMSession iSession = (IBMSession) request.getSession();
iSession.setAttribute("name", "Bob");
//force write to external store
iSession.sync( )
When using database persistence, if an attempt is made to update session values and the database is down or is having difficulty connecting, three connection attempts are made to the database before it finally creates a connection error (SESN0038E). For each connection attempt that fails, a StaleConnectionException is created and recorded in the log files. If the database opens 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 as previously described, 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 approximately 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.
While session management can recover from a database outage, an architecture where the connection to the database is not a single point of failure is strongly recommended.
Related
Session management tuning
Concept topic