InfoCenter Home > 4.4.1.1.8: Best practices for session programmingWhen developing new objects to be stored in the HTTP session, make sure to implement the Serializable interface. This enables the object to properly persist session information to the database. An example of this is: public class MyObject implements java.io.Serializable {...} Without this extension, the object will not persist correctly and will throw an error. When adding Java objects to a session, make sure they are in the correct class path. If Java objects will be added to a session, be sure to place the class files for those objects in the application server class path or in the web application path. In the case of session clustering, this applies to every node in the cluster. Because the HttpSession object is shared among servlets that the user might access, consider adopting a site-wide naming convention to avoid conflicts. Also, if objects are only in the web application class path and more than one web application is sharing sessions, the following restrictions apply:
Do not store large Object graphs in HttpSession. In most applications, each servlet requires only a fraction of the total session data. However, by storing the data in HttpSession as one large object, an application forces WebSphere to process all of it each time. Release HttpSession objects when you are finished. HttpSession objects live inside the WebSphere servlet engine until:
Do not try to save and reuse the HttpSession object outside of each servlet or JSP. The HttpSession object is a function of the HttpRequest (you can get it only through req.getSession() ), and a copy of it is valid only for the life of the service() method of the servlet or JSP. You cannot cache the HttpSession object and refer to it outside the scope of a servlet or JSP. Use session affinity to help achieve higher cache hits. The plug-in reads the cookie data (or encoded URL) from the browser and helps direct the request to the appropriate application or clone based on the assigned session key. This helps to achieve a greater use of the in-memory cache and reduces hits to the session database. Maximize use of session affinity and avoid breaking affinity. Using session affinity properly can enhance the performance of WebSphere. Session affinity in WebSphere is a way to maximize the use of the in-memory cache of session objects and reduce the amount of reads to the database. Session affinity works by caching the session objects in the JVM of the application with which a user is interacting. If there are multiple clones of this application, the user can be directed to any one of the clones that are also in their own JVM. If the users starts on clone1 and then comes in on clone2 a little later, all of the session information must be persisted to the database and then read by the JVM in which clone2 is running. This database read can be avoided by using session affinity. With session affinity, the user would start on clone1 for the first request; then for every successive request, the user would be directed back to clone1. By doing this, clone1 has to look only at the cache to get the session information; clone1 never has to make a call to the session database to get the information. You can improve performance by not breaking session affinity. Some suggestions to help avoid breaking session affinity are:
When applying security to servlets or JSPs that use sessions, secure all of the pages (not just some). When it comes to security and sessions, it's all or nothing. It does not make sense to protect access to session state only part of the time. When WebSphere security is enabled, all resources from which a session is created or accessed must be either secured or unsecured. You cannot mix secured and unsecured resources. The problem with securing only a couple of pages is that sessions created in secured pages are created under the identity of the authenticated user. They can be accessed in other secured pages only by the same user. To protect these sessions from use by unauthorized users, they cannot be accessed from an unsecure page. When a request from an unsecure page occurs, access is denied and an UnauthorizedSessionRequestException is thrown. (UnauthorizedSessionRequestException is a run-time exception; it is logged for you.) Use manual update and sync() in applications that mostly read session data but update infrequently. When an application is using a session, the LastAccess time field is updated any time data is read from or written to that session. If persistent sessions are being used, this produces a new write to the database. This performance hit can be avoided by using manual update and having the record written back to the database only when data values are updated, not on every read or write of the record. To use manual update, you first need to turn it on in the Session Manager. In addition, the application code must use com.ibm.websphere.servlet.session.IBMSession instead of the generic HttpSession class. Within IBMSession, the sync() method tells the application server that the data in the session object should be written out to the database. This enables the developer to improve overall performance by having the session information persist only when necessary. When using multiframe Java Server Pages (JSP), create the session for the frame page (JSP) but do not create it for the pages (JSPs) within the frame. By default, JSPs create HTTPSession objects by calling the request.getSession(true) method. By doing this, each page in the browser is requesting a new session, but only one session is used per browser instance. You can use <%@ page session="false"%> to turn off the automatic session creation. Then if the page needs to access session information, use <% HttpSession session = javax.servlet.http.HttpServletRequest.getSession(false); %> to get the already existing session that was created by the frame JSP. This enables you to not break session affinity on the initial loading of the frame pages. Implement the following suggestions to achieve high performance:
For more information, see the following IBM documents on the Web:
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|