This subsection describes how to implement an application considering the update frequency of the objects stored in an HTTP session and how to check the implementation using the J2EE server log.
Smaller the update frequency of the objects stored in an HTTP session, better the memory efficiency of the Explicit memory block. For example, if you invoke multiple setAttribute methods with the same value in the first argument name, the objects in the second argument value are only updated for the number of times the method is invoked with the same value. This is the update frequency of the object.
If the objects stored in an HTTP session are updated, the objects before update are used, but that memory area is not released until the HTTP session is destroyed. Therefore the lower the update frequency the better the memory efficiency. Note that there is no problem if the object updates are repeated in short cycles (cycles of about 10 times or less of the copy garbage collection interval), but if the updates are repeated in long cycles, the object becomes a long life span object and is moved to the Explicit memory block. The objects that are transferred to the Explicit memory block are not released until the HTTP session is destroyed even if the object has already been used. If the Explicit Memory Management functionality is not applied, such objects are released when a full garbage collection occurs. Typically, in systems where the survival duration of an HTTP session is long, for example the HTTP session is not destroyed during the day, the object updates might be easily repeated in long cycles.
From the application design point of view, if the update frequency of the objects stored in an HTTP session increases, consider the following points to determine the applicability of the Explicit Memory Management functionality:
You check the update frequency of the objects stored in an HTTP session from the contents of the thread dump.
To check:
"CCC#HttpSession" eid=97(0x02f25610)/R, total 16K, used 8K, garbage 0K (50.1% used/total, 0.0% garbage/used, 0 blocks) Enable |
This point describes the mechanism by which the used HTTP session-related objects remain in the Explicit memory block as a result of repeated updates. The objects described here are long life-span objects with survival duration shorter than the destruction of an HTTP session.
The following figure shows the differences in the object release processing when the Explicit Memory Management functionality is enabled and when the functionality is disabled.
Figure A-3 Object release processing when the Explicit Memory Management functionality is enabled and when the functionality is disabled
This figure is an example of an HTTP session that is not destroyed for a long time. With Time 2, four objects are used up due to an object update. With Time 3, when the Explicit Memory Management functionality is disabled, the Tenured area size exceeds the threshold value for the occurrence of a full garbage collection, so the full garbage collection (in the figure, FullGC occurs is applicable) occurs, and the used objects are released. When the Explicit Memory Management functionality is enabled, the full garbage collection does not occur, so the used objects remain behind and are not released. Furthermore, even after the lapse of Time n, the HTTP session is not yet destroyed. When the Explicit Memory Management functionality is disabled, the used objects of the Tenured area are released with the occurrence of the threshold value-based full garbage collection. When the Explicit Memory Management functionality is enabled, the automatic release processing does not occur until the HTTP session is destroyed, so the used up and un-released objects remain behind and the possibility of Explicit heap overflow increases.
By Time n in this example, there are 16 objects that are used up and have not been released, but in a system that requires an HTTP session that is not destroyed for a long time (for example, during a day), there might be a situation in which even more used objects are not released.