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 是否会导致数据库状态不一致？

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

Answer 1

好吧，我花了一些时间才弄清楚。答案是否定的，如果我们禁用 com.atomikos.icatch.enable_logging，我们就无法保证事务的一致性，我们最终可能会在一个数据库中提交一些内容，而在另一个数据库中没有提交。

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

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

此时事务协调器在幕后进行控制。 准备消息被发送给每个参与者。 每个参与者都以 READY TO COMMIT 或 ABORT 响应，消息被强制写入日志。 如果所有参与者都以 COMMIT 响应。向每个参与者发送一个提交调用。

这意味着，如果发生崩溃并且事务日志在协调器端（即 Atomikos）被禁用，则很有可能一个参与者设法提交，而另一个参与者没有设法提交。

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

Answer 2

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