The following tracking methods are available:
Session tracking with cookies
Tracking sessions with cookies is the default. No special programming is required to track sessions with cookies.
Session tracking with URL rewriting
An application that uses URL rewriting to track sessions must adhere to certain programming guidelines. The application developer needs to do the following:
Program servlets to encode URLs.
Depending on whether the servlet is returning URLs to the browser or redirecting them, include either the encodeURL method or the encodeRedirectURL method in the servlet code. Examples demonstrating what to replace in your current servlet code follow.
Suppose you currently have this statement:
Change the servlet to call the encodeURL method before sending the URL to the output stream:
out.println("<a href='"); out.println(response.encodeURL("/store/catalog")); out.println("'>catalog</a>");
Suppose you currently have the following statement:
Change the servlet to call the encodeRedirectURL method before sending the URL to the output stream:
The encodeURL method and encodeRedirectURL method are part of the HttpServletResponse object. These calls check to see if URL rewriting is configured before encoding the URL. If it is not configured, the calls return the original URL.
If both cookies and URL rewriting are enabled and the response.encodeURL method or encodeRedirectURL method is called, the URL is encoded, even if the browser making the HTTP request processed the session cookie.
You can also configure session support to enable protocol switch rewriting. When this option is enabled, the product encodes the URL with the session ID for switching between HTTP and HTTPS protocols.
Supply a servlet or JSP file as an entry point
The entry point to an application, such as the initial screen presented, may not require the use of sessions. However, if the application in general requires session support (meaning some part of it, such as a servlet, requires session support), then after a session is created, all URLs are encoded to perpetuate the session ID for the servlet (or other application component) requiring the session support.
The following example shows how you can embed Java code within a JSP file:
<% response.encodeURL ("/store/catalog"); %>
Session tracking with SSL information
No special programming is required to track sessions with Secure Sockets Layer (SSL) information.
To use SSL information, turn on Enable SSL ID tracking in the session management property page. Because the SSL session ID is negotiated between the Web browser and HTTP server, this ID cannot survive an HTTP server failure. However, the failure of an application server does not affect the SSL session ID if an external HTTP server is present between WebSphere Application Server and the browser.
SSL tracking is supported for the IBM HTTP Server and iPlanet Web servers only. You can control the lifetime of an SSL session ID by configuring options in the Web server. For example, in the IBM HTTP Server, set the configuration variable SSLV3TIMEOUT to provide an adequate lifetime for the SSL session ID. An interval that is too short can cause a premature termination of a session. Also, some Web browsers might have their own timers that affect the lifetime of the SSL session ID. These Web browsers may not leave the SSL session ID active long enough to serve as a useful mechanism for session tracking. The internal HTTP Server of WebSphere Application Server also supports SSL tracking.
When using the SSL session ID as the session tracking mechanism in a cloned environment, use either cookies or URL rewriting to maintain session affinity. The cookie or rewritten URL contains session affinity information that enables the Web server to properly route a session back to the same server for each request.
Controlling write operations
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. This interface 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 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", "Mikalai"); //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 three attempts before it finally creates a BackedHashtable.getConnectionError error. For each connection attempt that fails, the BackedHashtable.StaleConnectionException is created and can be found in the sync() method. 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, 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 that is created 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.