5.3.3 HTTP session attributes that are inherited as global session information

This subsection describes the following items related to the HTTP session attributes that can be inherited when a failure occurs.

Conditions for the HTTP session attributes that can be inherited
Objects supported as target for inheriting
Can or cannot inherit the session information depending on object contents
Notes on serialize processing when inheriting HTTP session attributes
Notes on deserialize processing when inheriting HTTP session attributes
Notes for when HTTP session attributes are inherited

Organization of this subsection

(1) Conditions for the HTTP session attributes that can be inherited
(2) Objects supported as targets for inheriting
(3) Conditions for inheriting the session information depending on object contents
(4) Notes on serialize processing when inheriting HTTP session attributes
(5) Notes on deserialize processing when inheriting HTTP session attributes
(6) Notes for when HTTP session attributes are inherited

(1) Conditions for the HTTP session attributes that can be inherited

In the session failover functionality, serialization of objects occurs in update processing of the global session information and deserialization of objects occurs in inherit processing. Hence, attributes to be registered in an HTTP session must satisfy the following condition:

It is an object of serializable class that has implemented the java.io.Serializable interface.

To Page Top

(2) Objects supported as targets for inheriting

With the session failover functionality, the following objects of serializable classes are supported as targets for inheriting:

Objects of the classes provided by a J2EE application.
Objects of the classes provided on J2SE.

However, with inheritance processing, it is not checked whether an object of a serializable class, which is registered in an HTTP session, is supported by the session failover functionality.

To Page Top

(3) Conditions for inheriting the session information depending on object contents

The following table describes whether you can or cannot inherit the session information depending on the contents of objects registered in an HTTP session.

Table 5‒3: Conditions for inheriting the session information depending on the contents of objects registered in an HTTP session
No.	Contents of objects registered in an HTTP session		Can or cannot inherit the session information	Storing global session information
No.	Implementation status of the java.io.Serializable interface	Serialization successful/failed	Can or cannot inherit the session information	Storing global session information
1	The `java.io.Serializable` interface implemented	Serialization successful	Can be inherited.	Information after serialization is stored in a database.
2	The `java.io.Serializable` interface implemented	Serialization failed	Cannot be inherited because HTTP sessions containing attributes, which failed in serialization, are not targeted for inheriting a global session.	The KDJE34318-E or KDJE34411-E message is output and the global session information is not stored in a database. After completing request processing the next time, the global session information is stored in a database when objects registered in an HTTP session become serializable.
3	The `java.io.Serializable` interface not implemented	(Cannot be serialized)	Cannot be inherited because attributes that cannot be serialized cannot be targeted for inheriting the global session.	If there are objects that cannot be serialized, the KDJE34317-W or KDJE34410-W message is output and the global session information that is created with the attributes excluding attributes that cannot be serialized, is stored in a database.

To Page Top

(4) Notes on serialize processing when inheriting HTTP session attributes

Notes on serialize processing are as follows:

(a) Impact of serialize processing on performance

The serialize processing is executed not only for the objects targeted for inheriting but also for all the objects that are referenced from the objects targeted for inheriting. Hence, if you register a class containing information, which need not be inherited, in an HTTP session, performance might deteriorate.

(b) When the java.lang.OutOfMemoryError error occurs

In the serialize processing, data after serialization is temporarily created exceeding the number of HttpSession objects set in the application. As a result, if you register huge objects in an HTTP session, the java.lang.OutOfMemoryError error might occur while creating the global session information.

(c) When serialization fails and its measures

In the following cases, the KDJE34317-W, KDJE34318-E, KDJE34410-W, or KDJE34411-E message is output and serialization fails.

If objects referenced from the objects registered in an HTTP session (objects of serializable classes) include the objects for which classes other than serializable classes are implemented.
If the writeObject (java.io.OutputStream out) method is implemented in objects and if an exception occurs when serializing.

If serialization fails, processing for updating and inheriting the global session information is not executed. To execute the processing, you must take one of the following actions:

Cancel the registration of objects that failed in serialization, in an HTTP session.
Change the objects that failed in serialization and eliminate the cause of failure.

To Page Top

(5) Notes on deserialize processing when inheriting HTTP session attributes

Deserialization fails in the following cases:

If you add changes that cause failure in deserialization in a Web application and if the Web application is different than in the case of serialization.
If the readObject (java.io.OutputStream out) method is implemented in objects and if an exception occurs when deserializing.

If deserialization of session information fails when receiving a request or in the processing of inheriting global session information when starting a Web application, global session information and session information is deleted, and KDJE34326-E or KDJE34413-E is output. Because inheriting of the session fails, the request is processed in the absence of an HTTP session.

To Page Top

(6) Notes for when HTTP session attributes are inherited

In a configuration in which the integrity mode is not used and multiple requests are executed for one session, thread-unsafe objects must not be stored in the session. (Contention with Cosminexus-side processing cannot be avoided even if a thread-safe implementation is achieved by using, for example, the synchronized clause in the user program.)

To Page Top