Hard ICE question 2

[marco ves]

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 ves]

Come on people

[Axel Janssen]

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 ]

[Mano Poreddy]

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 !!

[Sandeep Chaturvedi]

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.

[Axel Janssen]

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.

[Manish Sarlashkar]

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