Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures

Home

Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips

Books

Submit News
Search the site here...
Search...
 
Search the JavaFAQ.nu
1000 Java Tips ebook

1000 Java Tips - Click here for the high resolution copy!1000 Java Tips - Click here for the high resolution copy!

Java Screensaver, take it here

Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java programming articles and tips. Please take your copy here.

Take your copy of free "Java Technology Screensaver"!.

Read Java Certification SCBCD Study Guide - 6. Session Bean Component Contract

JavaFAQ Home » Java Certification Books and Tests Go to all tips in Java Certification Books and Tests


Bookmark and Share

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:
  • A serializable object.
  • A null.
  • An enterprise bean’s remote interface reference.
  • An enterprise bean’s remote home interface reference.
  • An entity bean’s local interface reference.
  • An entity bean’s local home interface reference.
  • A reference to the SessionContext object.
  • A reference to the environment naming context (java:comp/env JNDI)
  • A reference to the UserTransaction interface.
  • A reference to a resource manager connection factory.
  • An object that is not directly serializable, because it contains references on "non-serializable" objects mentioned above.

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.

Identify the interface and method for each of the following: retrieve the session bean's remote home interface, retrieve the session bean's local component interface, determine if the session bean's caller has a particular role, allow the instance to mark the current transaction as a rollback, retrieve the UserTransaction interface, prepare the instance for reuse following passivation, release resources prior to removal, identify the invoker of the bean instance's component interface, be notified that a new transaction has begun, and be notified that the current transaction has completed.

A container provides the session bean instances with a SessionContext, which gives the session bean instance access to the instance’s context maintained by the container. The SessionContext interface has the following methods:
  • The getEJBObject method returns the session bean’s remote interface.
  • The getEJBHome method returns the session bean’s remote home interface.
  • The getEJBLocalObject method returns the session bean’s local interface.
  • The getEJBLocalHome method returns the session bean’s local home interface.
  • The getCallerPrincipal method returns the java.security.Principal that identifies the invoker of the bean instance’s EJB object.
  • The isCallerInRole method tests if the session bean instance’s caller has a particular role.
  • The setRollbackOnly method allows the instance to mark the current transaction such that the only outcome of the transaction is a rollback. ONLY instances of a session bean with CONTAINER-managed transaction (CMT) demarcation can use this method.
  • The getRollbackOnly method allows the instance to test if the current transaction has been marked for rollback. ONLY instances of a session bean with CONTAINER-managed transaction (CMT) demarcation can use this method.
  • The getUserTransaction method returns the javax.transaction.UserTransaction interface. The instance can use this interface to demarcate transactions and to obtain transaction status. ONLY instances of a session bean with BEAN-managed transaction demarcation (BMT) can use this method.
		public interface SessionContext extends EJBContext {
		   EJBLocalObject getEJBLocalObject() throws IllegalStateException;
		   EJBObject getEJBObject() throws IllegalStateException;
		}

		public interface EJBContext {
		   EJBHome getEJBHome();
		   EJBLocalHome getEJBLocalHome();
		   java.security.Principal getCallerPrincipal();
		   boolean isCallerInRole(String roleName);
		   UserTransaction getUserTransaction() throws IllegalStateException;
		   void setRollbackOnly() throws IllegalStateException;
		   boolean getRollbackOnly() throws IllegalStateException;
		}

		/**
		* This interface represents the abstract notion of a principal, which
		* can be used to represent any entity, such as an individual, a
		* corporation, and a login id.
		*/
		public interface Principal {
		   public String getName();
		}
	

The ejbRemove notification signals that the instance is in the process of being removed by the container. In the ejbRemove method, the instance typically releases the same resources that it releases in the ejbPassivate method.

The Bean Provider CANNOT assume that the Container will always invoke the ejbRemove() method on a session bean instance. The following scenarios result in ejbRemove() NOT being called on an instance:
  • A crash of the EJB Container.
  • A SYSTEM exception thrown from the instance’s method to the Container.
  • A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB Container implementation specific way.
If the session bean instance allocates resources in the ejbCreate<METHOD>(...) method and/or in the business methods, and normally releases the resources in the ejbRemove() method, these resources will not be automatically released in the above scenarios. The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.

The ejbPassivate notification signals the intent of the container to passivate the instance. The ejbActivate notification signals the instance it has just been reactivated. Because containers automatically maintain the conversational state of a session bean instance when it is passivated, most session beans can ignore these notifications. Their purpose is to allow session beans to maintain those open resources that need to be closed prior to an instance’s passivation and then reopened during an instance’s activation (for example, DB connections).

A STATEFUL session bean class (CMT only) can optionally implement the javax.ejb.SessionSynchronization interface. This interface provides the session bean instances with transaction synchronization notifications. The instances can use these notifications, for example, to manage database data they may cache within transactions :
  • The afterBegin notification signals a session bean instance that a new transaction has begun. The container invokes this method before the first business method within a transaction (which is not necessarily at the beginning of the transaction). The afterBegin notification is invoked with the transaction context. The instance may do any database work it requires within the scope of the transaction.
  • The beforeCompletion notification is issued when a session bean instance’s client has completed work on its current transaction but prior to committing the resource managers used by the instance. At this time, the instance should write out any database updates it has cached. The instance can cause the transaction to roll back by invoking the setRollbackOnly method on its session context.
  • The afterCompletion notification signals that the current transaction has completed. A completion status of true indicates that the transaction has committed; a status of false indicates that a rollback has occurred. Since a session bean instance’s conversational state is not transactional, it may need to manually reset its state if a rollback occurred.
		public interface SessionSynchronization {
		   void afterBegin() throws EJBException, RemoteException;
		   void afterCompletion(boolean committed) throws EJBException, RemoteException;
		   void beforeCompletion() throws EJBException, RemoteException;
		}
	
ONLY a STATEFUL Session bean with CONTAINER-managed transaction (CMT) demarcation may implement the SessionSynchronization interface. A stateless Session bean MUST NOT implement the SessionSynchronization interface.
IBA JV

 Printer Friendly Page  Printer Friendly Page
 Send to a Friend  Send to a Friend

.. Bookmark and Share

Search here again if you need more info!
Custom Search



Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

RSS feed Java FAQ RSS feed Java FAQ News     

    RSS feed Java Forums RSS feed Java Forums

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

Interactive software released under GNU GPL, Code Credits, Privacy Policy