Appendix A.1 Considering the life span of the objects stored in an HTTP session

This subsection describes how to implement an application considering the life span of the objects stored in an HTTP session and how to check the implementation using the J2EE server log.

Organization of this subsection
(1) Considerations for the implementation of applications
(2) How to check using the J2EE server log
(3) Mechanism of using the objects stored in an HTTP session after the HTTP session is destroyed

(1) Considerations for the implementation of applications

We recommend that only the objects released when an HTTP session is destroyed be stored in an HTTP session. If the percentage of such objects is high, the time taken for the automatic release processing reduces. If there are objects that remain even after the HTTP session is destroyed, a new Explicit memory block is generated, the objects are transferred to that block, and are subject to the subsequent automatic release processing. Also, the transferred objects do not support the HTTP session.

With the Explicit Memory Management functionality, the objects referenced directly or indirectly from the objects stored in the HTTP session using the setAttribute method are assumed to have been stored in the HTTP session. These objects move to the Explicit memory block according to the timing of promotion. If the reference relationship from the objects stored in the HTTP session becomes complicated, there is a higher possibility that the objects that continue to be used even after the HTTP session is destroyed are stored in the HTTP session.

Therefore, we recommend that the objects to be stored in an HTTP session be made as simple as possible, such as the String type objects and the objects storing the primitive type or primitive type array.

From the application design point of view, if the objects that continue to be used even after the HTTP session is destroyed must be stored in the HTTP session, consider using the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality. For details on the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, see 8.10 Reducing the time taken for the automatic release processing of the Explicit memory block in the uCosminexus Application Server Expansion Guide.

(2) How to check using the J2EE server log

You check the life span of the objects stored in an HTTP session from the contents of the thread dump.

To check:

  1. Start the J2EE server, and execute the general business until the HTTP session is destroyed.
  2. After the HTTP session is destroyed, execute the eheapprof command to obtain the thread dump.
  3. Find the Explicit memory block where <EM_NAME> is NULL.
    If a NULL Explicit memory block does not exist, this indicates that no objects continue to be used even after the HTTP session is destroyed.
    If a NULL Explicit memory block exists, check the value of used (used size of the Explicit memory block).
    An example of output is as follows:

    "NULL" eid=1(0x02f25610)/A, total 542K, used 501K, garbage 0K (92.4% used/total, 0.0% garbage/used, 0 blocks) Enable

    This indicates that this Explicit memory block has objects that continue to be used even after the HTTP session is destroyed. However, if the used value is from a few kilobytes to a few megabytes, the impact during the automatic release processing is not great.

(3) Mechanism of using the objects stored in an HTTP session after the HTTP session is destroyed

This section describes the mechanism by which the objects stored in an HTTP session are used even after the HTTP session is destroyed. As a typical example, the following figure shows an example of referencing the common data (object) from the objects stored in an HTTP session.

Figure A-1 Example of referencing the common data (object) from the objects stored in an HTTP session

[Figure]

In this example, the setAttribute method is used to reference the common data, object A, from the objects stored in an HTTP session. The object A does not appear to have been stored in an HTTP session, but due to the transfer of objects based on a reference relationship, the object is moved to an Explicit memory block corresponding to an HTTP session at the reference source. In this example, the object is assumed to have moved to the Explicit memory block 1. For details on the transfer of objects based on a reference relationship, see 8.6.5 Transferring the objects based on a reference relationship from the Java heap to the Explicit memory block in the uCosminexus Application Server Expansion Guide.

Thereafter, if the HTTP session corresponding to the Explicit memory block 1 is destroyed and the automatic release processing occurs, the object A referenced from outside (Explicit memory block that is not a target of the release processing) is moved to the new Explicit memory block x. This Explicit memory block x does not support the HTTP session. The following figure shows the status of the Explicit memory block after the HTTP session is destroyed.

Figure A-2 Status of the Explicit memory block after the HTTP session is destroyed

[Figure]

Greater the number of objects in use in the target Explicit memory block, longer is the time taken by the automatic release processing corresponding to the destruction of the HTTP session. Also, the objects, which are being used during the automatic release processing corresponding to the destruction of the HTTP session, are moved to an Explicit memory block that does not support the HTTP session, and are subject to the automatic release processing. The longer the period, during which these objects cannot be released, the higher the frequency at which these objects become subject to the automatic release processing and this might lead to deterioration in the throughput and latency.

In this example, the references to the common data, object A, last until one of the n number of HTTP sessions is destroyed. During this time, the automatic release processing of the new Explicit memory block x is repeated and the operation becomes inefficient. If the size of the common data is small, the impact is not particularly great, but in the case of hundreds of megabytes or more, the impact on the automatic release processing time is great, and might cause deterioration in the throughput and latency.