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

2020年3月3日 12点热度 0条评论

我想了解如果我设置了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?

    解决方案如下:

    好吧,我花了一些时间才弄清楚。如果我们禁用com.atomikos.icatch.enable_logging,答案是“否”,则我们不能保证事务的一致性,并且最终某些事情可以提交到一个数据库中,而不能提交到另一个数据库中。

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

    发生的事情是,首先XA事务中的所有参与者都要向协调员注册。
    XA_START
    然后进入记录阶段,其中所有sql语句都分派(dispatch)给不同的参与者
    XA_END 表示此过程的结束以及从应用程序角度调用commit的时刻。

    此时,事务处理协调器将在后台进行控制。
    PREPARE消息发送给每个参与者。
    每个参与者都以“准备提交”或“中止”响应,该消息被强制发送到日志。
    如果所有参与者都以COMMIT答复。提交调用将发送给每个参与者。

    这意味着,如果发生崩溃,并且在作为Atomikos的协调器端禁用了事务日志记录,则这是一个参与者设法提交COMMIT而另一个参与者没有提交 promise 的合理机会。

    基本上,如果您要保证状态一致,则com.atomikos.icatch.enable_logging是必需的。