HTTP Session Managemet - Restricting approach

HTTP Session management - a frequent discussion point in many projects and frequent reason for performance issues in the projects. Recently I happened to review a project which takes nearly 5 mins to load a page that contains a table data. And after visiting this page application becoming slow. Reason is, application retrieves all data in one call and stores it in session scope and is not removed after traversing out of the page.Time and again managers feel need for design that controls session usage. Recently I initiated a discussion on IASA forum to gather ideas from community. I always felt HTTP session proper usage should be more of guidelines than framework. But if session timeout is more than usual 20mins, we might have to go for policing policy. Based on responses in the forum and my experience I think of below solution.

1. Applications cant totally avoid session but should limit the usage. So while design identify the objects required to be maintained in HTTP session. Create a Class which will act as place holder for all data to be kept in session. This will be POJO with the objects that require to be kept in session as fields. So only objects that have setter method on this object can be set to session.


2. Add a Session Listener. This will be a class implementing HTTPSessionListener. This need to be configured in web.xml. There are three methods in this interface. One of the will get executed whenever an attribute is added. This method in listener implementation should remove the added attribute excepting the predefined ones. (Apart from the object of above class, application container will keep some objects in session. Listener should discount them too. This will restrict the HTTP Session usage)


3. Container object created in step1 can have a public method to calculate the size of itself (which means size of objects in session). Application can use this method for auditing like displaying http session data from application on a special page etc.


4. Above solves one part of the problem, application still need to take care of clearing the data (by assigning null to the field). This can be taken care by application code. If need to be part of framework you can provide a configuration file which defines permitted data for each action/module. Define a some Intercepting filter that will examine the Container object and remove the unwanted data.

Its easy to implement and maintain. As every one agree its good design and implementation adhering to design that will result in good application