Wolf-Dieter Fink wrote:
Throwing a RuntimeException should prompt the container to flag the transaction as failed CMT, in your case the transaction is not finished and this will be an abnormal method end.
I'm not sure I fully understand what you meant by "failed CMT". In the example I gave there is no CMT. There is a client transaction and BMT started in the bean method.
My understanding is the following.As the method throws RT exception the BMT is rolled back. Then the client recieves EJBException (with RT exception inside) which is caught by the catch block.So normally client transaction should not be affected.
This case is described in O’Reilly "Enterprise JavaBeans 3.1".
CMT = Container Managed Transaction, I compare CMT with BMT in that case.
As you throw a RuntimeException (described as SystemException in your book) the Vendor (here JBoss) 'may or may not' mark the Tx for rollback, so this behavior is conform to the spec.
Also it is a undefined behaviour if you not end the Tx in your bean and the result may different in different container. For me it is consistent if the transaction (include the clients one) is rolled back.
Thanks for your answer. I think there is a bit of misunderstanding here.
Just to clearify. My case is :
1. the client start a client transaction.
2. the client calls a BMT bean (client transaction is suspended)
3. the BMT bean starts a new transaction
4. the BMT throws a runtime exception
If I get you right, your point is - the client transaction may (or may not) be marked for rollback.
My point is - according to the book and the spec the client transaction should not be affected.
Below is the table from the spec decribing the case. Only the transaction started by the BMT bean is rolled back. There is nothing about client transaction there.
I think that is because of the UserTransaction you have received from the container.
I suppose that, if you close the Tx via commit/rollback, the client transaction is not affected and can continue.
Only if you let the container in this undefined state it will end in that way.
IMHO it is not against the specification, but
I agree with you that the spec and even some documentations are not very clear, also I've seen some where it is wrong in some cases but this can be a issue with different container version