Browse Prior Art Database

SessionGarbageCollection - Minimizing Session Size in a J2EE Application

IP.com Disclosure Number: IPCOM000010732D
Original Publication Date: 2003-Jan-15
Included in the Prior Art Database: 2003-Jan-15
Document File: 4 page(s) / 78K

Publishing Venue

IBM

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 4

SessionGarbageCollection - Minimizing Session Size in a J2EE Application

   This article describes an effective way to keep the size of the session in a J2EE application to a minimal. This improves response times of requests, especially over a period of time of the application usage.

Introduction

With the large scale adoption of the J2EE programming model, enterprises are increasingly adopting the servlet API to write server side java code. The J2EE 1.3 specification includes the servlet 2.3 API. Several applications written to the predecessor levels 2.1 and 2.2 must now be modified to comply with the new specification. The HttpSession object plays an important role in the application. It is used to store data in the session scope till it can transport the data over the to the controller layer for further processing. In J2EE applications, objects stored in the session that need to be processed by the EJB layer or the business tier, require serialization. This is an expensive operation. This makes the need for keeping session data small, very important. We will see how this could affect performance of the application and how we could ensure that the session object has minimal information at any given time.

Sessions - Key points to keep in mind

Applications must keep the size of the session small in order to improve overall performance. It is important to keep the object graph simple and ensure that the objects are serializable if they need to be persisted or passed as parameters to EJBs.

Overview

In a typical J2EE application, there is a horizontal distribution of the developers, based on the components of the application. Each component would require to add some information to the session object, which does not need to remain in the session object once the control of the application goes to another component. If this session data is not cleaned up periodically, it causes a large amount of data to be serialized every time a request is sent to the middle tier to get results of a user-button-click or a similar action. This would deteriorate the performance of the application over a period of time.

This can be easily understood with the help of a sample scenario -

A banking application - In a simple sectional of a web-based banking application, there is a JSP with two links on the left navigator - Check Balance and Transfer funds. Each of these functionalities has multiple tabs in the page.(e.g. Check Balance comprises "Select Account" and "All Accounts" tabs. Transfer Funds has "From Account", "To Account", "Amount", "Password" tabs). The data entered by a user needs to be in the session between tabs for the same functionality, but do not need to remain across the functionalities. One way of achieving this - The JSP has a call to remove the session attributes that

1

Page 2 of 4

were set the last time this component was accessed. What this does is, clean up the session data for CheckBalance only when control comes back to the CheckBalanc...