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

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

Answer 2

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

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

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

此时，事务协调员在幕后进行控制。 PREPARE消息被发送给每个参与者。 每个参与者都响应READ TO COMMIT或ABORT消息被强制写入日志。 如果所有参与者都以COMMIT回复。提交调用将发送给每个参与者。

这意味着如果发生崩溃并且在协调器端禁用了事务日志记录，那么Atomikos就是一个参与者设法COMMIT而另一个参与者无法提交的公平机会。

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