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.

When you are not using the Explicit Memory Management functionality, many times, these objects are continued to be used during multiple executions of a copy garbage collection. Therefore, these objects are easy to rise to the Tenured area as long-life objects. Because objects that rise to the Tenured area are not recovered by a copy garbage collection, these objects are not recovered even after the session is destroyed. This leads to an increase in the memory usage of the Tenured area and a full garbage collection occurs.

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

Figure 8-7 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 multiple executions of the copy garbage collection, the objects in step 1 and 2 move to the Tenured area. Although the session deactivates in step 3, objects in the Tenured area are not recovered and the memory usage goes on increasing.

You can inhibit the occurrence of the full garbage collection by changing the rise destination of objects related to the HTTP session from the Tenured area to the Explicit heap.

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

Figure 8-8 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. Thus you can inhibit the occurrence of a full garbage collection. 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. After multiple executions of the copy garbage collection, when the corresponding Java object rises, the object moves 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. After multiple executions of the copy garbage collection, when the corresponding Java object rises, the object moves 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 not targeted for the garbage collection. 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.

Even if you change the attributes by using the setAttribute method, the area that was using the object is not released because the attributes prior to change are not targeted for the garbage collection.

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 reserved for release are actually released when the copy garbage collection or full garbage collection is executed after that. 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.

• 8.7 Releasing Explicit memory blocks when the automatic release functionality is enabled
• 8.8 Releasing Explicit memory blocks when 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 8-4 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

Apart from the HTTP session, the Web application + 2^# Explicit memory blocks are used inside the Web container for objects for the HTTP session management.

#: Because two objects for management are kept internally in the Web container, add that count as well.

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 8.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 Efficiently using Explicit heaps to be used in HTTP session in the uCosminexus Application Server System Design Guide, you can efficiently apply the Explicit Memory Management functionality to a HTTP session.