Stateful Session Bean Lifecycle

By Nithya Vasudevan

  • A session bean instance’s life starts when a client obtains a reference to a stateful session bean instance through dependency injection or JNDI lookup.
  • Next, the container performs any dependency injection as specified by metadata annotations on the bean class or by the deployment descriptor.
  • The container then calls the PostConstruct lifecycle callback interceptor method(s) for the bean, if any.
  • The container then returns the session object reference to the client. The instance is now in the method ready state and ready for client’s business methods.
  • A business method is executed either in a transaction context or with an unspecified transaction context (shown as “tx method” and “non-tx method” in the diagram).
  • 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 (before any business method) and the instance becomes associated with the transaction.
  • If a client attempts to invoke a method on the session object in a different transaction context than the one with which the instance is currently associated or in an unspecified transaction context, an error occurs.
  • 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).
  • When the transaction completes, the container issues afterCompletion on the instance, specifying the status of the completion (either commit or rollback).
  • 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 invokes the PrePassivate lifecycle callback interceptor method(s) for the bean instance, if any. 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 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 invokes the PostActivate method for the instance, if any. The session bean instance is again ready for client methods.
  • When the client calls a business method of the bean that has been designated as a Remove method, the container invokes PreDestroy lifecycle callback interceptor method(s) (if any) for the bean instance after the Remove method completes. This ends the life of the session bean instance and the associated session object.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Stateful Session Bean State ManagementStateful Session Beans
Stateful Session Bean’s Lifecycle Callback MethodsStateful Session Beans