Atomikos事务日志com.atomikos.icatch.enable_logging=false

Question

我想了解如果我设置com.atomikos.icatch.enable_logging=false，分布式事务功能是否适用于我的应用程序。

• 我是否正确地理解，在出现崩溃的情况下，事务恢复是相关的，并且我们希望完全重新启动同一事务。
• 恢复是否在同一个分布式事务中工作？
• 我的应用程序可以容忍失败，因为从一开始就可以用新事务重新启动失败。这是否意味着在我的例子中设置com.atomikos.icatch.enable_logging=false是可以的
• 如果没有提交分布式事务的所有参与者，com.atomikos.icatch.enable_logging=false会导致数据库的不一致状态吗？

更新i是在这个问题发生后触发的，目的是了解更多关于分布式事务的内部结构，我在这里描述了：How would you tune Distributed ( XA ) transaction for performance?

Answer 1

我花了些时间才弄明白。答案是否定的，如果我们禁用com.atomikos.icatch.enable_logging，我们不能保证事务的一致性，并且我们最终可能会在一个数据库中提交一些东西，而在另一个数据库中没有提交。

在XA事务中，我们有两个主要角色。事务协调器和事务参与者。涉及两个事务日志。一方面，协调员的事务日志和参与者的事务日志。

首先，XA事务中的所有参与者都向协调器注册。然后，XA_START遵循一个记录阶段，所有的sql语句都被分派给不同的参与者，XA_END标志着这个过程的结束，以及从应用程序的角度调用提交的时刻。

此时，事务协调器在幕后进行控制。准备信息发送给每个参与者。每个参与者的响应都准备好提交或中止消息，将消息强制发送到日志中。如果所有参与者都响应提交。将提交调用发送给每个参与者。

这意味着，如果在协调程序端(即Atomikos )禁用了事务日志记录，那么它们是一个公平的机会，一个参与者设法提交，而另一个参与者则无法提交。

基本上，如果您想要保证一致的状态，com.atomikos.icatch.enable_logging是强制性的。

Answer 2

如果您想要分布式事务，那么您可能也希望启用日志记录。禁用它实际上只用于测试配置。