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. 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 Web container 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. 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 with security integration enabled, 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 security integration is enabled in Session Manager, 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 either sync() or time-based write 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. Although manual update gives you the most precise control for sending updates, the use of time-based write and scheduled invalidation options can also help the case in which access is frequent but updating is not. 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:
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|