JTA Transaction management ambiguity

[Florin Vasile]

Hello guys,

I have one question, maybe on of you could enlighten me. I've seen in enthuware kit that there are a lot of questions regarding transaction management and exception management so I started learning the transaction-related chapters from the EJB spec.

in EJB Spec, table 15:

Bean method runs in the context of a transaction that the container started immediately before dispatching the business method.
This case may happen with Required and RequiresNew attributes.

For a system Exception the client receives an EJBException but what puzzles me is that "If the client executes in a transaction, the client’s transaction may or may not be marked for rollback."

On what does this depend?


Thank you!

[Singh Harmeet]

in the JTA transaction , when the transaction is failed , the container automatically roll back the transaction . when the exception is throw the EJBContext class setRollBackOnly() method automatically call to roll back the transaction.

[Jaikiran Pai]

Florin Vasile wrote:
Bean method runs in the context of a transaction that the container started immediately before dispatching the business method.
This case may happen with Required and RequiresNew attributes.

For a system Exception the client receives an EJBException but what puzzles me is that "If the client executes in a transaction, the client’s transaction may or may not be marked for rollback."

On what does this depend?

It depends on in what context the bean method executed. If the bean used a "Requires new" transaction attribute and the client was already running in a transaction, then on a system exception, the client's transaction will not be marked for rollback. If however, the bean was running in a "require" transaction attribute and the client was already running in a transaction, then that transaction will be propagated to the bean and any system exceptions throw will then result in the client's transaction being marked for rollback.

[Florin Vasile]

Hello,

Thank you for your answers. But I may not have expressed myself clear enough.

The specification says that even in the eventuality that the client runs in one transaction and our bean runs in a separate transaction (our bean has the attribute RequiresNew or NotSupported) and an exception is thrown, the client's transaction "may or may not be rolledback".

[Bobby Jakachira]

Client's transaction context is important always.

A..If the client has a transaction context, it means he wants the process to be transactional - atomic principle applied, all or nothing

B..if the client does not have a transaction context, then it's quite possible that the client does not mind the atomicity of the proccess.

For A, a method with the REQUIRES_NEW transaction attribute will NOT mark the client's transaction for roll back if an exception happens, system exceptions and application exceptions marked to achieve a rollback, because the transaction running is not the client's one. The new transaction will be rolled-back but the client's transaction will continue. REQUIRED attribute will mark the client's transaction for rollback because the method will run using the client's transaction and thus it will be affected directly.

For, B, No client's transaction context means on the client's perspective nothing will be marked for rollback because there is no transaction to talk about. The client will not even know that there are transactions, if any, running behind the scenes.

[Florin Vasile]

Hello Bobby,

I agree with most of what you've said, but the case that the spec is pointing out is the one in which client has a transaction context running and the method is running in the a transaction context opened by the container before the dispatch is being made (so the case of RequiresNew). I would have initially assumed that the client's transaction wouldn't be rolled back but the spec says that it may or may not be rolled back.

Please review the table Table 15 of section 14.3.1 from ejb-3.1-fr-spec.pdf. "Handling of Exceptions Thrown by a Business Interface Method or No-interface View Method of a Bean with Container-Managed Transaction Demarcation".

Method condition: "Bean method runs in the context of a transaction that the container started immediately before dispatching the business method. This case may happen with Required and RequiresNew attributes."
System Exception => Client view: "Receives EJBException. If the client executes in a transaction, the client’s transaction may or may not be marked for rollback." => if the client executes in a transaction and the method condition is fulfilled => that the TransactionAttribute is RequiresNew.

[Bobby Jakachira]

I understand but with a REQUIRES_NEW transaction attribute defined on the method being called by the client in a transaction context there is No way the client's transaction can be marked for roll back. The client itself should decide after catching the exception whether to rollback or continue. It cannot be marked for rollback because the method does not have the handle to client's transaction. I also do not think the container can even act on it because doing so will certainly create parallel open transactions. It CAN ONLY be marked for roll back by the client himself should he think that the exception received from such method warrants a rollback.

Client - tx1

MethodA - tx2 (with RequiresNew)

Client calls MethodA with transaction tx1, the container suspends client's transaction tx1 and the container creates transaction tx2. If MethodA then throws an exception that requires a rollback, ONLY transaction tx2 will be marked for rollback when the methodA finishes. At this stage the MethodA does not have a handle to tthe ransaction tx1 and cannot do anything about it. The client will then get an exception and decides whether to mark the transaction for rollback or not.

Please correct me if I am wrong, I need to be sure that I understand this part correctly.

[Florin Vasile]

I have found the answer in the book Enterprise JavaBeans 3.1 6th edition from O'Reilly:

"The EJB's transaction was rolled back. The client's transaction may be marked for rollback, depending on the vendor".