ENTITY BEAN LIFE CYCLE: ALLOWED METHODS.

Dear Folks, I am trying to come up with rationale for the allowed and not allowed operations for entity beans to better recollect them. Most of the Whys and Why nots I don't know and most of the ones I have come up with maybe inaccurate. I am using Valentine Cretazz's cheat sheet and looking for help from all of you to fill in the blanks and expand upon it and give your reasons, please. If there is a resource that better explains this please direct me to it.

REASONS: 1) How can it call the Home Object when its the container of a CMP Entity bean that creates and sets the context and the bean and puts them back into the pool ? (as per page 326 of HFEJB) 2) I can't think of a reason why java:comp/env access ought to be available or the other access unavailable. 3) Transactions are not allowed at setEntityContext(ec) because the bean is not ready for transactions yet considering its context could have been created and set just for the pool by the container to be later initialized with entity data. 4) Client information cannot be accessed at setEntityContext(ec) because the client could not have existed at a stage when the bean and its context could have been created and set just for the pool by the container to be later initialized with entity data. 5) Database connections and other EJB access are not allowed at setEntityContext(ec) because the bean and its context do not even know what entity data they will be initialized with and have been created and set just for the pool by the container. 6) The EJBObject/ EJBLocalObject calls are not allowed because the EJB Object does not exist at this point in the lifecycle of the entity bean because the container is creating and setting the context and the bean just to pool it.

REASONS: 1) I can't think of a reason why getEJBHome()/ getEJBLocalHome() access ought to be available or the other access unavailable? Why would it need access to EJB Home ? to remove itself at this stage ? to get EJBMetaData about itself? to get a handle to itself at this stage? 2) I can't think of a reason why java:comp/env access ought to be available or the other access unavailable. 3) It is conceivable that the home business method could be in the middle of a transaction at this stage because even though its pooled it does contain the entity information since passivated entity beans are live objects on the heap. 4) Since an entity bean is bound to have a client the home business method at this stage, because only a client can call this method, the bean can request security information of the client. 5) It is conceivable that the home business method could would a DB connection or reference to another EJB because even though its pooled and it does contain the entity information since passivate entity beans are live objects on the heap. 6) Since you are calling the Home Business Method of a pooled bean there is no reason why it should have access to the EJBObject. It is self sufficient in its data manipulation at this point.

REASONS: 1) Its conceivable that a DB row being created might want to get hold of getEJBHome()/ getEJBLocalHome() to run some finder or select or business home methods which might determine the data being inserted into the database. 2) Its conceivable that a DB row being created might want to get hold of an environment variable with data which it could use to initialize its columns before they are inserted into the database. 3) It is conceivable that the create method could be in the middle of a transaction at this stage because data insertion, update and delete could be tied to a transaction where either all succeeds or all fails and is rolled back. For example transfer of money (delete money from Account A only if Account B's money is deleted). 4) Since an entity bean is bound to have a client if its asking the container to insert data into the database the bean can request security information of the client. 5) It is conceivable that the create method could want a DB connection since its after all inserting a row into the DB. It is likely that a reference to another EJB maybe requested since that other bean could hold information that might influence the data inserted. 6) At ejbCreate<Method>(args) the primary key is generated and therefore you cannot call getPrimaryKey from the EJBObject/ EJBLocalObject. You cannot access EJBObject because in entity beans the EJBObject is created and sent back to the client only after the row is inserted into the database.

REASONS: 1) Its conceivable that a DB row being created might want to get hold of getEJBHome()/ getEJBLocalHome() to run some finder or select or business home methods which might determine the data being inserted into the database. 2) Its conceivable that a DB row being created might want to get hold of an environment variable with data which it could use to initialize its columns before they are inserted into the database. 3) It is conceivable that the create method could be in the middle of a transaction at this stage because data insertion, update and delete could be tied to a transaction where either all succeeds or all fails and is rolled back. For example transfer of money (delete money from Account A only if Account B's money is deleted). 4) Since an entity bean is bound to have a client if its asking the container to insert data into the database the bean can request security information of the client. 5) It is conceivable that the create method could want a DB connection since its after all inserting a row into the DB. It is likely that a reference to another EJB maybe requested since that other bean could hold information that might influence the data inserted. 6) At ejbCreate<Method>(args) the primary key is generated and therefore you cannot call getPrimaryKey from the EJBObject/ EJBLocalObject. You cannot access EJBObject because in entity beans the EJBObject is created and sent back to the client only after the row is inserted into the database.

rule1### to access other method in bean or to access resource manager the method should be in Transaction

rule2### to access getRollbackOnly or setRollbackOnly for CMT beans the method should be in transaction

for entity beans business methods,remove,finder,create,home business methods should be in Transaction .So they follow above rule.

rule3### to use UserTransaction methods for BMT the method should be in transaction

For MDB only onMessage method requires Transaction.so all the above rules apply to MDB.

for session beans only business method, afterBegin(stateful),beforeCompletion(stateful) requires transaction, so they follow above rules

there is one exceptional case that ejbCreate ,ejbActivate,ejbPassivate,ejbRemove(all methods here have same bean things) can still access other beans and resource manager

Arthur Orange
Ranch Hand

Joined: Dec 29, 2004
Posts: 30

posted Jan 07, 2005 09:37:00

0

Originally posted by Krishnaraj Govindaraju: rule1### to access other method in bean or to access resource manager the method should be in Transaction

Are you saying that in order to access ANOTHER EJB or resource manager (comp/jdbc for e.g.) you need to be in a transaction? by transaction you are excluding "unspecified transaction context", right? Its informative but how does it help ?

Originally posted by Krishnaraj Govindaraju:

rule2### to access getRollbackOnly or setRollbackOnly for CMT beans the method should be in transaction

Thats common sense-ical and obvious.

Originally posted by Krishnaraj Govindaraju:

for entity beans business methods,remove,finder,create,home business methods should be in Transaction .So they follow above rule.

Finders/Select methods in entity beans are never in transactions, right.

Originally posted by Krishnaraj Govindaraju:

rule3### to use UserTransaction methods for BMT the method should be in transaction

For MDB only onMessage method requires Transaction.so all the above rules apply to MDB.

for session beans only business method, afterBegin(stateful),beforeCompletion(stateful) requires transaction, so they follow above rules

there is one exceptional case that ejbCreate ,ejbActivate,ejbPassivate,ejbRemove(all methods here have same bean things) can still access other beans and resource manager

The exception is for CMT stateful session bean only right? but i had to look that up from Valentine's cheat sheets on life cycle diagrams.

These guiding rules are all that is needed to decipher the allowed methods in stages of a lifecycle? I guess not I wish there was a more detailed and cogent explanation for the reasons why certain methods are permitted in certain stages of the life cycle and reasons why other method calls are not permitted.