Here is the question. While testing a BMP entity bean, a developer discovers that a transaction rollback does not cause a rollback of the changes made to the bean as it should. Which of the following should the developer suspect? A.The ejbPassivate() method has a bug. B.The ejbStore() method has a bug. C.The ejbCreate() method has a bug. D.The datastore does not support JTA. E.The transaction does not implement javax.transaction.UserTransaction. Select 2 answers. I think that the answer must be D and E because the rollback for entity beans is handled by the container and is out of the programmers hands. So, there is no point in checking ejbPassivate() ejbStore() method , ejbCreate() for bugs. Does anyone have any input?
Marco, its b, d. same question was in 158. why. heck. why. Am thinking. its most obvious. B. The ejbStore() method has a bug. there is something I cant remember. Someone knows? D. The datastore does not support JTA. O.k. This is obvious for me. [ June 11, 2003: Message edited by: Axel Janssen ]
i;m for sure its not "E" bcs it has no meaning and doesn't convey anything?? reg B, as its BMP any failures in transcations can be caught and it wouldn;t stop thread from execting,so it will not stop container from calling ejbStore()?? hope u got my point !!
I think if there is a bug with the transaction rollback, it means - developer has not either not set setRollBackOnly() or called it in wrong place. This could happen in ejbStore() or ejbCreate. I dont think you can use Entity Bean if the data provider does not support JTA.
Joined: Jan 08, 2001
don't think that ejbCreate is right choice, because of
discovers that a transaction rollback does not cause a rollback of the changes made to the bean as it should
ejbCreate is only called, when new data is inserted in datasource. Here is no insert but a update.
hi, Let me try to answer the question by analyzing each option. Please correct if I am wrong. The answer is, 'b' and 'd'. A. The ejbPassivate() method has a bug. ---> The ejbPassivate() (should) never have any Data access api even in case of BMP. Also, the ejbPassivate() executes without Tx context , so there is no way this method can corrupt a transaction. *So this is not a correct answer. B. The ejbStore() method has a bug. ---> The ejbStore() is executed at the end of the Transaction (with a Tx context of business method) and if the bean provider accindently calls the Tx api of the resource manager(database), this can corrupt the transaction. For example, in a BMP entity bean if a method starts a transaction and commits it, and within this scope, if you call commit() on java.sql.connection (obtained from DataSource), the data is commited in DB, but also the container throws a java.lang.IllegalStateException and rolls back the transaction. So, your transaction is rolled back but the data is committed (means the state is not rolled back). ** So this is one of the right answers. C. The ejbCreate() method has a bug. --->The question is for, when data is changed and not when data is created. **So this is not a correct answer. D. The datastore does not support JTA. --> This indicates that the Datasource does not support an external Tx manager and handles only local Tx. [Still trying to understand.... ]. ** So this can be a right choice. E. The transaction does not implement javax.transaction.UserTransaction --> All containers, according to EJB 1.1 spec, must at least implement, javax.transaction.UserTransaction interface. So choice 'E' can not be true. ** So this can not be a correct answer. Thank you, -Manish