Recipe 2.3: Reducing HttpSession object size
The size of HttpSession object becomes heavy and degrades your application performance if you put all user specific data in it.
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
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?
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.
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.