Best practices for session programming

Best practices for session programming

Before you develop new objects to be stored in the HTTP session, make sure to consider enabling security integration. HTTP sessions are identified by session IDs, which are pseudo-random numbers that are generated at runtime. Session hijacking is a known attack on HTTP sessions and can be prevented if all requests going over the network are over a secure connection (HTTPS). Not every configuration in a customer environment enforces the security constraint because of potential SSL performance impacts, and HTTP sessions can become vulnerable to hijacking. WAS can integrate HTTP sessions and application server security. Enable security in WAS to protect sessions so that only session creators have access to those sessions.

When developing new objects to be stored in the HTTP session, make sure to implement the Serializable interface. Also ensure the java objects contained within your class are Serializable. 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 is not correctly persisted throws an error.

When adding Java objects to a session, make sure they are in the correct class path. If Java objects are added to a session, be sure to place the class files for those objects in the application server class path or in the Web module 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. For more information, see Distributed session support.

Note: 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 WAS to process all of it each time.

Release HttpSession objects when you are finished. HttpSession objects live inside the Web container until one of the following occur:

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.

Note: Do not try to save and reuse the HttpSession object outside of each servlet or JSP.

The HttpSession object is a function of the HttpServletRequest: you can get it only through the getSession() method. A copy of the HttpSession object 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.

Distributed sessions require an affinity mechanism so that all requests for a particular session are directed to the same Java virtual machine in the cell. This conforms to the Servlet 2.3 Specification in that multiple requests for a session cannot coexist in multiple virtual machines. One such solution provided by WAS is serialized session access, which is available as part of the WebSphere plug-ins for various Web servers.

If one of the servers in the cell fails, it is possible for the request to be rerouted to another server. 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.