Recipe 2.3: Reducing HttpSession object size

Problem

The size of HttpSession object becomes heavy and degrades your application performance if you put all user specific data in it.

Background

Although HttpSession object is meant to store user input data, it is oftencan be misused as a user cache and when it is used to store other user session specific data such as user’s search results. For instance, in an application in which the user enters search criteria, often large amounts of search results The search results are retrieved from the database and in general the amount of search results is greater than user input data. So When you use HttpSession object to store the data that comes from the database , it becomes heavy and degrades your application performance.

This impact will happen both when the HttpSession objects are maintained in memory (default) and when they are persisted to a data store. The decision of whether to use in-memory or persistent sessions depends up on the application requirement and the deployment model. If you do not want to lose the session data in case of server failure then choose persistent sessions so that session data is stored in a database and is available after the server restarts. This is normally configured in your application server/Servlet container. Otherwise session data is maintained in memory by default and the data is lost in case of server failure. If your application is deployed in a clustered environment then you have to choose persistent sessions or in-memory replication since all servers need to share session data.

When your application maintains session data in memory and if you store user specific data such as search results, that data stays in memory until the session times out. Because the search interface typically is not bound to logoff feature and when users leave the website after using the search feature you cannot programmatically remove session data sooner. So search results stay in memory unnecessarily and degrade performance.

In case of persistent sessions, storing search results in HttpSession object can lead to not only redundant session data, and but also serialization overhead. When you configure session data as persistent, Servlet container automatically stores session data in its proprietary schema and tables. It serializes HttpSession object before storing it to the database and de-serializes it after retrieving from the database.

Figure 4.5 shows how HttpSession object is used to store user's input data (shopping cart items) and user's search results (retrieved from user defined ITEMS table in the database). When it is persisted, the Servlet container's session manager stores the session data same search results retrieved from ITEMS table) in its proprietary SESSIONS table to make the session data available in case of server failure.

The problem here is that it is redundant to store the search results in two tables. Further more, there is a lot of serialization and de-serialization overhead. So storing large user specific data that is retrieved from database in HttpSession object leads to poor performance.

So how can we minimize HttpSession object size and improve the application performance?

Recipe

Divide the user specific data into two categories; the user data that comes from the browser as user input and the user data that comes from the database as output and use HttpSession object to store only user input data. You can use technique described in Recipe ‘Googling large results’ to display the user specific data that comes from the database such as search results and product items. This approach gives good results in web applications by allowing programmer to remove when it is combined with HttpSession objects after user session activity with log off feature as described in Rrecipe 'Removing HttpSession objects programmatically', in which the HttpSession objects are removed from memory at the time the user logs off and reduced its overhead.

Storing only user input data in HttpSession object also gives excellent results in case of persistent sessions by reducing redundant data and database calls. Figure 4.6 depicts fine-grained approach, which does not impose any extra overhead in case of persistent sessions.

Figure 4.6 shows how HttpSession object is used to store only user input data such as shopping cart items, which avoids redundant session data storage and makes lightweight HttpSession objects. With this approach, the size of HttpSession is reduced to a great extent since in general the amount of user input data is comparatively less than search results.

Discussion

Your Application server/Servlet container may support other options to make sessions available to different servers in a clustered environment such as file storage and in-memory replication. You can configure appropriate option in your Application server. In case of file storage option, the HttpSession objects will be stored in file system and in case of in-memory replication, the HttpSession objects will be replicated in memory of different servers without touching persistent store. If your application server supports all these options, you can consider either in-memory replication or database persistence option to protect HttpSession data from fail-over, and you can ignore the file persistent option because file storage is costlier than these options. Irrespective of these available options, reducing HttpSession objects size with this recipe’s approach improves application performance.