ejbLoad and ejbStore


EJB programming & troubleshooting: ejbLoad and ejbStore

  1. ejbLoad and ejbStore (4 messages)

    hi, is there any way to call Load and store from the client pgm..

    Threaded Messages (4)

  2. No You cannot![ Go to top ]

    See Prasanna!, The ejbLoad() & ejbStore() methods belong to EntityBean class and not EjbObject class.So when you look up some bean, you never get the actual bean instance, the server gives you a EjbObject object.These methods are called by container like the container may call ejbLoad() before every transaction begin and ejbStore() after transaction completion. You can call all the methods of EjbObject like remove(), getHandle() etc. Keep in mind, ejbStore,ejbLoad,EjbActivate, all these are called by container to give you the services for which you are using ejb. cheers, http://javaicillusion.blogspot.com/
  3. ejb passivate and ejbactivate[ Go to top ]

    hi, can u just explain ejbPasivate and ejbActivate method in entity beans ..how it is difference from session beans
  4. Re: ejb passivate and ejbactivate[ Go to top ]

    The following steps describe the life cycle of an entity bean instance: • An entity bean instance’s life starts when the container creates the instance using newInstance. The container then invokes the setEntityContext method to pass the instance a reference to the EntityContext interface. The EntityContext interface allows the instance to invoke services provided by the container and to obtain the information about the caller of a client-invoked method. • The instance enters the pool of available instances. Each entity bean has its own pool. While the instance is in the available pool, the instance is not associated with any particular entity object identity. All instances in the pool are considered equivalent, and therefore any instance can be assigned by the container to any entity object identity at the transition to the ready state. While the instance is in the pooled state, the container may use the instance to execute any of the entity bean’s finder methods (shown as ejbFind in the diagram) or any of the entity bean’s home methods (shown ejbHome in the diagram). The instance does not move to the ready state during the execution of a finder or a home method. An ejbSelect method may be called by an entity bean’s home method while the instance is in the pooled state. • An instance transitions from the pooled state to the ready state when the container selects that instance to service a client call to an entity object or an ejbTimeout method. There are two possible transitions from the pooled to the ready state: through the ejbCreate and ejbPostCreate methods, or through the ejbActivate method. The container invokes the ejbCreate and ejbPostCreate methods when the instance is assigned to an entity object during entity object creation (i.e., when the client invokes a create method on the entity bean’s home object). The container invokes the ejbActivate method on an instance when an instance needs to be activated to service an invocation on an existing entity object—this occurs because there is no suitable instance in the ready state to service the client’s call or the ejbTimeout method. • When an entity bean instance is in the ready state, the instance is associated with a specific entity object identity. While the instance is in the ready state, the container can synchronize the state of the instance with the state of the entity in the underlying data source whenever it determines the need to, in the process invoking the ejbLoad and ejbStore methods zero or more times. A business method can be invoked on the instance zero or more times. The ejb- Timeout method can be invoked on the instance zero or more times. Invocations of the ejb- Load and ejbStore methods can be arbitrarily mixed with invocations of business methods and ejbTimeout method invocations. An ejbSelect method can be called by a business method (or ejbLoad or ejbStore method or ejbTimeout method ) while the instance is in the ready state. • The container can choose to passivate an entity bean instance within a transaction. To passivate an instance, the container first invokes the ejbStore method to allow the instance to prepare itself for the synchronization of the database state with the instance’s state, and then the container invokes the ejbPassivate method to return the instance to the pooled state. • Eventually, the container will transition the instance to the pooled state. There are three possible transitions from the ready to the pooled state: through the ejbPassivate method, through the ejbRemove method, and because of a transaction rollback for ejbCreate, ejbPostCreate, or ejbRemove (not shown in Figure 14). The container invokes the ejbPassivate method when the container wants to disassociate the instance from the entity object identity without removing the entity object. The container invokes the ejbRemove method when the container is removing the entity object (i.e., when the client invoked the remove method on the entity object’s component interface or a remove method on the entity bean’s home interface). If ejbCreate, ejbPostCreate, or ejbRemove is called Instance Life Cycle Contract Between the Bean and the ContainerEnterprise JavaBeans 3.0, Final ReleaseEJB 2.1 Entity Bean Compo- Sun Microsystems, Inc. and the transaction rolls back, the container will transition the bean instance to the pooled state. • When the instance is put back into the pool, it is no longer associated with an entity object identity. The container can assign the instance to any entity object within the same entity bean home. • The container can remove an instance in the pool by calling the unsetEntityContext method on the instance. Notes: 1. The EntityContext interface passed by the container to the instance in the setEntity- Context method is an interface, not a class that contains static information. For example, the result of the EntityContext.getPrimaryKey method might be different each time an instance moves from the pooled state to the ready state, and the result of the getCaller- Principal and isCallerInRole methods may be different in each business method. 2. A RuntimeException thrown from any method of an entity bean class (including the business methods and the callbacks invoked by the container) results in the transition to the “does not exist? state. The container must not invoke any method on the instance after a Runtime- Exception has been caught. From the caller’s perspective, the corresponding entity object continues to exist. The client can continue accessing the entity object through its component interface because the container can use a different entity bean instance to delegate the client’s requests. Exception handling is described further in Chapter 14. 3. The container is not required to maintain a pool of instances in the pooled state. The pooling approach is an example of a possible implementation, but it is not the required implementation. Whether the container uses a pool or not has no bearing on the entity bean coding style.
  5. Re: ejb passivate and ejbactivate[ Go to top ]

    Hi, Just to add what Arijit said (as he has very exhaustive explnation :) thanks for that) is: When ejbActivate() method call from container brings the EntityBean's instance from Pool state to Ready state. And after this ejbLoad() method is being called by the Container. Now the key point to notice is that before calling ejbActivate() the container already associate the EntityBean's instance with the EJBObject which requires the Bean instance to fulfill the client request. So, this will enable Container to get the information from EJBObject for the EntityContext like "primaryKey" / "ejb Object" / "ejb home" local or remote etc. This information eventually is used by the Container (CMP) or Bean (BMP) to load the current state of the bean from the Persistence Store in ejbLoad() method. so, I think it key to remember that before calling ejbActivate(), Container associate bean with the EJBObejct instance. I think this will make it more clear. Thanks and Regards, Manish Malhotra