Atomikos transaction logs com.atomikos.icatch.enable_logging=false

Question

I would like to understand if the Distributed Transaction Capabilities will work for my application if I set the com.atomikos.icatch.enable_logging=false

• Do I understand correctly that the Transaction Recovery is relevant in the cases where there has been a crash, and we want to completely restart the same transaction.
• Does the recovery work within the same distributed transaction?
• My application is tolerant to failures in terms that a failure can always just be restarted from the start with a new transaction. Does this mean that in my case it is ok to set com.atomikos.icatch.enable_logging=false
• Can com.atomikos.icatch.enable_logging=false lead to inconsistent state of the database if not all participants of the distributed transactions have been committed?

Update I was triggered after this problem to learn a little bit more about the internals of the distributed transactions which I have described here : How would you tune Distributed ( XA ) transaction for performance?

Answer 1

Well it took me some time to figure it out. The answer is NO if we disable the com.atomikos.icatch.enable_logging we can not guarantee transactional consistency and we can end up with some things committed in one database and not committed in another.

In XA transaction we have two main roles. Transaction coordinator and transaction participant. There are two transactional logs involved. The transactional log of the Coordinator on one hand and the transactional log of the participant.

What happens is that first all participants in an XA transaction register themselves to the coordinator. XA_START then follows a recording phase where all sql statements are dispatched towards the different participants XA_END marks the end of this process and moment when from application perspective commit is invoked.

At this point the Transaction Coordinator takes control behind the scenes. PREPARE message is sent to each participant. Each participant responds with READY TO COMMIT or ABORT the message is forced to the logs. If all participants respond with COMMIT. A commit invocation is sent to each participant.

This mean that if there is a crash and the transactional logging is disabled at the coordinator side which is Atomikos their is a fair chance that one participant manages to COMMIT and another participant do not manage to commit.

Basically the com.atomikos.icatch.enable_logging is mandatory if you want to guarantee consistent state.