Chapter 4. Session Bean Life Cycle

A session bean instance’s life starts when a client invokes a create<METHOD>(...) method on the session bean’s home interface. This causes the container to invoke newInstance() on the session bean class to create a new session bean instance. Next, the container calls setSessionContext() and ejbCreate<METHOD>(...) on the instance and returns the session object reference to the client. The instance is now in the METHOD READY STATE.

The session bean instance is now ready for client’s business methods. Based on the transaction attributes in the session bean’s deployment descriptor and the transaction context associated with the client’s invocation, a business method is executed either in a transaction context or with an unspecified transaction context.

A non-transactional method is executed while the instance is in the METHOD READY STATE.

An invocation of a transactional method causes the instance to be included in a transaction. When the session bean instance is included in a transaction, the container issues the afterBegin() method on it. The afterBegin is delivered to the instance before any business method is executed as part of the transaction. The instance becomes associated with the transaction and will remain associated with the transaction until the transaction completes.

Session bean methods invoked by the client in this transaction can now be delegated to the bean instance. An error occurs if a client attempts to invoke a method on the session object and the deployment descriptor for the method requires that the container invoke the method in a different transaction context than the one with which the instance is currently associated or in an unspecified transaction context.

If a transaction commit has been requested, the transaction service notifies the container of the commit request before actually committing the transaction, and the container issues a beforeCompletion on the instance. When beforeCompletion is invoked, the instance should write any cached updates to the database. If a transaction rollback had been requested instead, the rollback status is reached without the container issuing a beforeCompletion. The container may not call the beforeCompletion method if the transaction has been marked for rollback (nor does the instance write any cached updates to the database).

The transaction service then attempts to commit the transaction, resulting in either a commit or rollback.

When the transaction completes, the container issues afterCompletion on the instance, specifying the status of the completion (either commit or rollback). If a rollback occurred, the bean instance may need to reset its conversational state back to the value it had at the beginning of the transaction.

The container’s caching algorithm may decide that the bean instance should be evicted from memory (this could be done at the end of each method, or by using an LRU policy). The container issues ejbPassivate on the instance. After this completes, the container saves the instance’s state to secondary storage. A session bean can be passivated only between transactions, and NOT within a transaction.

While the instance is in the passivated state, the Container may remove the session object after the expiration of a timeout specified by the deployer. All object references and handles for the session object become invalid. If a client attempts to invoke the session object, the Container will throw the java.rmi.NoSuchObjectException if the client is a remote client, or the javax.ejb.NoSuchObjectLocalException if the client is a local client.

If a client invokes a session object whose session bean instance has been passivated, the container will activate the instance. To activate the session bean instance, the container restores the instance’s state from secondary storage and issues ejbActivate on it.

The session bean instance is again ready for client methods.

When the client calls remove() on the home or component interface to remove the session object, the container issues ejbRemove() on the bean instance. This ends the life of the session bean instance and the associated session object. Any subsequent attempt by its client to invoke the session object causes the java.rmi.NoSuchObjectException to be thrown if the client is a remote client, or the javax.ejb.NoSuchObjectLocalException if the client is a local client. (The java.rmi.NoSuchObjectException is a subclass of the java.rmi.RemoteException; the javax.ejb.NoSuchObjectLocalException is a subclass of the javax.ejb.EJBException). The ejbRemove() method cannot be called when the instance is participating in a transaction. An attempt to remove a session object while the object is in a transaction will cause the container to throw the javax.ejb.RemoveException to the client. Note that a container can also invoke the ejbRemove() method on the instance without a client call to remove the session object after the lifetime of the EJB object has expired.

A stateless session bean instance’s life starts when the container invokes newInstance() on the session bean class to create a new instance. Next, the container calls setSessionContext() followed by ejbCreate() on the instance. The container can perform the instance creation at any time—there is NO relationship to a client’s invocation of the create() method.

The session bean instance is now ready to be delegated a business method call from any client.

When the container no longer needs the instance (usually when the container wants to reduce the number of instances in the method-ready pool), the container invokes ejbRemove() on it. This ends the life of the stateless session bean instance.

Visit http://java.boot.by  for the updates.