Question

几天来，我们的日志已经充满了这条消息

2018-06-15 12:19:23 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c has 1 heuristic participant(s)!
2018-06-15 12:19:23 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c, node_name=acme_node, branch_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08d, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6569a57c >
2018-06-15 12:19:23 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c restored heuristic participant XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c, node_name=acme_node, branch_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08d, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6569a57c >

它始终是相同的Xid。有办法解决这个问题吗？我们正在考虑优雅地关闭应用程序并删除data / tx-object-store中的文件。这是个好主意吗？

使用WildFly 11.我们使用Oracle 12c和IBM WebSphere MQ设置了XA事务。我们正在从消息驱动的bean到JDBC进行XA事务。

Answer 1

我在交易指南的2.4.1. Assumed complete中找到了解决问题的方法。

如果在事务协调器告诉XAResource提交之后但在更新事务日志以删除参与者之前，在事务环境中发生故障，则恢复将尝试重播提交。对于序列化XAResource，来自XAResource的响应将使参与者能够从日志中删除，并在所有参与者都已提交后最终将其删除。但是，如果XAResource是不可恢复的，那么任何XAResourceRecovery实例都极不可能为恢复子系统提供新的XAResource来尝试进行恢复；在这种情况下，恢复将持续失败，并且日志条目将永远不会被删除。

有两个可能的解决方案：

依靠相关的ExpiryScanner最终将日志移到其他位置。然后需要手动干预，以确保可以安全删除日志。如果移动了日志条目，将输出适当的警告消息。

将com.arjuna.ats.jta.xaAssumeRecoveryComplete设置为true。每当无法从任何已注册的XAResourceRecovery实例中找到新的XAResource实例时，都会选中此选项。如果为false（默认值），恢复将假定XAResourceRecovery实例存在暂时性问题（例如，并非所有实例都已在子系统中注册），并将定期尝试恢复。如果为true，则恢复将假定先前的提交尝试已成功，并且可以从日志中删除此实例，而无需进行进一步的恢复尝试。此选项是全局选项，因此请谨慎使用，因为如果使用不当，XAResource实例可能会保持未提交状态。

Answer 2

有一个数据库事务未完成，您的服务器正在尝试恢复。检查insde

SERVER_HOME / standalone / data / tx-object-store / ShadowNoFileLockStore / defaultStore / StateManager / BasicAction / TwoPhaseCoordinator / AtomicAction /

有交易文件。也许首先删除事务文件（最好在您的本地/ dev环境中），然后尾随日志以标识未完成/提交的事务。修复问题的根源，警告将消失。或者，在“警告”上检查jndiName，以了解哪个数据源正在创建这些警告。

警告为“ 永无止境”，因为您可能有一个计划的任务，该任务不断尝试（以指定的时间间隔）与您的数据库进行通信，但是由于存在以下潜在的错误，交易从未完成您必须先修复。

永远不会结束启发式参与者的定期恢复

2 个答案: