7.4.1 Objects related to HTTP session

The objects stored in an HTTP session are the objects that are retained when the session is active. The objects exist from the generation of the session until the session is destroyed.

These objects are likely to be used continuously while copy GC is performed several times if the Explicit Memory Management functionality is not used. Therefore, these objects are easy to get promoted to the Tenured area as long-life objects. Because objects that have been promoted to the Tenured area are not reclaimed by copy GC, they remain even after the session is destroyed. For this reason, the amount of memory used for the Tenured area continues to increase, thus causing Full GC to occur.

The following figure shows an example of not using the Explicit Memory Management functionality

Figure 7‒6: An example of not using the Explicit Memory Management functionality

When you generate a session in step 1, the area for storing objects is secured in the New area. In step 2, objects are stored in a session. After copy GC occurs several times, the objects and their storage area are moved to the Tenured area. Although the session deactivates in step 3, objects in the Tenured area are not reclaimed and the memory usage goes on increasing.

In this situation, you can suppress occurrence of Full GC by changing where objects related to an HTTP session are moved from the Tenured area to the Explicit heap.

The following figure shows an example of using the Explicit Memory Management functionality

Figure 7‒7: An example of using the Explicit Memory Management functionality

If you use the Explicit Memory Management functionality, the Tenured area does not increase due to the objects related to an HTTP session. You can therefore suppress occurrence of Full GC. The J2EE server explicitly releases the Java objects placed in the Explicit heap after the session is destroyed.

This subsection describes the timing of securing and releasing the Explicit memory block area in which the HTTP session is to be placed.

When you create an HTTP session

When you create a new HTTP session, an Explicit memory block is created in the Explicit heap area. One Explicit memory block is allocated to one session. The HTTP session is secured inside the Explicit memory block.

However, objects are placed in the Java heap, immediately after a session is created. When Java objects that trigger GC are promoted after copy GC occurs several times, the objects are moved to the Explicit heap.

When an object is stored in the HTTP session (when setAttribute method is executed)

The javax.servlet.http.HttpSession.setAttribute method places the objects stored in the HTTP session, in Explicit memory blocks allocated to each session.

However, when the setAttribute method is executed, the objects are placed in the Java heap. When Java objects that trigger GC are promoted after copy GC occurs several times, the objects are moved to the Explicit heap. At that time, all the objects that were being referenced from the object to be moved are moved to the Explicit heap. However, the objects might not move to an Explicit heap depending on the specification of the option of controlling object movement to the Explicit memory block.

When the object is deleted from the HTTP session (when removeAttribute method is executed)

The Explicit heap is protected from GC. Therefore, even if you delete an object from the HTTP session by executing the javax.servlet.http.HttpSession.removeAttribute method, the area that was using the object is not released.

This also applies to attributes that are changed by using the setAttribute method, because GC is not performed for attributes that were set before they are changed.

The memory is released in Explicit memory blocks. Note that if your Web application repeatedly and frequently executes the setAttribute method, the area inside the Explicit memory block might get unnecessarily consumed even if you execute the removeAttribute method.

When the HTTP session is destroyed

When the HTTP session is destroyed, the Web container reserves the release of Explicit memory blocks created at the time of the HTTP session creation.

The Explicit memory blocks for which a reservation for release is made are actually released when copy GC or Full GC is performed later. At that time, all the areas reserved for release are released.

If references to objects stored in the session are retained after the Explicit memory blocks were released, see the following description.

• 7.7 Releasing Explicit memory blocks when the automatic release functionality is enabled

• 7.8 Releasing Explicit memory blocks when the automatic release functionality is disabled

The following table describes the mapping of an operation or an action executed by a Web application and a JavaVM action.

Table 7‒3: Mapping of operations executed by Web application (API) and JavaVM action

Operations (API) or actions executed by Web application	Web container action	JavaVM action
javax.servlet.http.HttpServletRequest.getSession() javax.servlet.http.HttpServletRequest.getSession(boolean)	Generating a session	Securing Explicit memory blocks
javax.servlet.http.HttpSession.setAttribute(String, Object)	Storing objects in the session	Placing objects in the Explicit memory block
Session timeout javax.servlet.http.HttpSession.invalidate()	Destroying the session	Releasing Explicit memory blocks

Note that you can reduce the memory size of the Explicit heap that is used in an HTTP session, by using the memory saving functionality of the Explicit heap. For details, see 7.11 Reducing memory usage of the Explicit heap that is used in an HTTP session.

If you implement an application by referring to Appendix A Efficient Usage of the Explicit Heap Used in an HTTP Session in the uCosminexus Application Server System Design Guide, you can efficiently apply the Explicit Memory Management functionality to a HTTP session.

To Page Top