InfoCenter Home >
4: Developing applications >
4.4: Personalizing applications >
4.4.1: Tracking sessions >
4.4.1.1: Session programming model and environment >
4.4.1.1.8: Best practices for session programming

4.4.1.1.8: Best practices for session programming

When 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:

  • The application explicitly and programmatically releases it using javax.servlet.http.HttpSession.invalidate(); quite often, programmatic invalidation is part of an application logout function.
  • The application server destroys the allocated HttpSession object when it expires (default is 1800 seconds or 30 minutes). When session persistence is used, the application server can maintain only a certain number of HttpSession objects in memory. When this limit is reached, The application server removes the least recently used session entries from the cache to make a room for new ones. If Allow Overflow is enabled, the product also uses an overflow memory table to cache the entries when there is a racing condition for a entry in the cache. The product makes its best effort to keep the cache at base memory size.

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.

Session clustering requires an affinity mechanism so that all requests for a particular session are directed to the same Java Virtual Machine (JVM) in the cluster. This conforms to the Servlet 2.2 Specification in that multiple requests for a session cannot coexist in multiple JVMs. One such solution provided by IBM WebSphere Application Server is Session Affinity, which is available as part of the WebSphere plug-ins for Web servers. If one of the servers in the cluster fails, it is possible for the request to be rerouted to another server in the cluster. The new server can access session data from the common SESSIONS table. This is transparent to the servlet, browser, and user. This helps to achieve a greater use of the in-memory cache and reduces hits to the session database.

Go to previous article: Tuning session support: Tablespace and page sizes Go to next article: Keeping user profiles

 

 
Go to previous article: Tuning session support: Tablespace and page sizes Go to next article: Keeping user profiles