Identify the use and the behavior of the ejbPassivate method in a session bean, including the responsibilities of both the container and the bean provider.

Bean Provider's responsibility

Passivation is performed only for STATEFUL session beans. The Bean Provider is required to ensure that the ejbPassivate method leaves the instance fields ready to be serialized by the Container. The objects that are assigned to the instance’s non-transient fields after the ejbPassivate method completes must be one of the following:

Bean Provider must close all JDBC™ connections in ejbPassivate and assign the instance’s fields storing the connections to null.

The Bean Provider must assume that the content of transient fields MAY be lost between the ejbPassivate and ejbActivate notifications.

Container's responsibility

The container performs the Java programming language Serialization (or its equivalent) of the instance’s state after it invokes the ejbPassivate method on the instance.

The container must be able to properly save and restore the reference to the home and component interfaces of the enterprise beans stored in the instance’s state even if the classes that implement the object references are not serializable.

If the session bean instance stores in its conversational state an object reference to the javax.ejb.SessionContext interface, java:comp/env JNDI context or UserTransaction interface, the container must be able to save and restore the object reference across the instance’s passivation.

The container may destroy a session bean instance if the instance does not meet the requirements for serialization after ejbPassivate.

While the container is not required to use the Serialization protocol for the Java programming language to store the state of a passivated session instance, it must achieve the equivalent result. The one exception is that containers are NOT REQUIRED to reset the value of transient fields during activation (as opposed to pure Serialization, which GUARANTEES that transient variables will come back with default values for that type).

Passivation typically happens spontaneously based on the needs of the container. It happens just BEFORE writing state to secondary storage.

Activation typically occurs when a client calls a method. It happens just AFTER reading state from secondary storage.

Professional hosting     Belorussian informational portal         Free SCWCD 1.4 Study Guide     Free SCDJWS 1.4 Study Guide     SCDJWS 1.4 Quiz     Free IBM Certified Associate Developer Study Guide     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     Free Mock Exam Engine