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.
SCJP 5.0 Simulator 642+ Questions With Explanations 