单个事务语音与Invalid_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事务中，我们有两个主要角色。交易协调员和交易参与者。涉及两个事务日志。协调器的事务日志和参与者的事务日志。

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

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

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

基本上，如果要保证一致状态，则必须使用com.atomikos.icatch.enable_logging。