5.5. 恢复 Heuristic Outcomes
当事务资源在分布式事务的完成阶段做出单边决策以提交或回滚事务更新时,会进行 heuristic completion。这可以使分布式数据处于不确定的状态。网络故障或资源超时可能是造成启发性完成的原因。启发性补全会产生以下启发性结果例外之一:
HEURISTIC_COMMIT- 当交易经理决定回滚时,会引发此例外,但在某些情况下,所有资源已自行提交。在这种情况下,您不需要进行任何操作,因为已达到一致的终止。
HEURISTIC_ROLLBACK-
这个例外意味着资源均已执行回滚,因为事务管理器的提交决定被延迟。与
HEURISTIC_COMMIT类似,在这种情况下,您也不需要做任何事情,因为已达到一致的终止。 HEURISTIC_HAZARD- 当有些更新的出现未知时,会出现这个例外。对于已知的对象,它们或者全部已提交,或者全部已回滚。
HEURISTIC_MIXED- 这个例外发生在交易的某些部分在提交时回滚。
此流程演示了如何使用 Jakarta Transactions 处理交易的启发式结果。
事务中的启发式成果的原因是资源经理承诺可以提交或回滚,然后无法履行承诺。这可能是因为第三方组件、第三方组件和 JBoss EAP 之间的集成层或 JBoss EAP 本身存在问题。
目前,导致启发式错误的最常见两个原因是环境中的瞬态故障,以及处理资源管理器的编码错误。
通常,如果您的环境中出现瞬态故障,您通常会在发现启发性错误前了解它。这可能是因为网络中断、硬件故障、数据库故障、电源中断或许多其他因素造成的。
如果在压力测试期间测试环境中发现了启发性的结果,这意味着您的测试环境存在缺点。
警告JBoss EAP 自动恢复出现故障时处于非修复状态的交易,但不试图恢复启发式交易。
如果您的环境中没有明显失败,或者启发式结果很容易再现,这可能是因为编码错误。您必须联系第三方供应商,以确定解决方案是否可用。
如果您怀疑问题在 JBoss EAP 本身的交易经理中,您必须提交支持票据。
- 您可以使用管理 CLI 尝试手动恢复事务。有关手动恢复事务的说明,请参阅恢复交易参与者 部分。
手动解决事务结果的过程取决于故障的确切情况。根据您的环境执行以下步骤:
- 确定涉及哪些资源管理器。
- 检查事务管理器和资源管理器的状态。
- 在一个或多个涉及的组件中手动强制进行日志清理和数据协调。
在测试环境中,或者如果您不关注数据的完整性,请删除事务日志并重新启动 JBoss EAP 将会去除启发式结果。默认情况下,事务日志位于单机服务器的
EAP_HOME/standalone/data/tx-object-store/目录中,或者位于受管域中的EAP_HOME/domain/servers/SERVER_NAME/data/tx-object-store/目录中。对于受管域,SERVE R_NAME 是指参与服务器组的单个服务器的名称。注意事务日志的位置还取决于使用的对象存储,以及为 object-store-
relative-to 和参数设置的值。对于文件系统日志,如标准 shadow 和 Apache ActiveMQ Artemis 日志,将使用默认的目录位置,但在使用 JDBC 对象存储时,事务日志存储在数据库中。object-store-path
5.5.1. 为 Heuristic Outcomes 进行决策指南 复制链接链接已复制到粘贴板!
问题检测
启发性决策是交易系统中可能出现的最重要的错误之一。这可能会导致部分交易被提交,而其他部分将被回滚。因此,它可能会违反事务的原子性属性,并可能导致数据完整性损坏。
可恢复的资源维护稳定存储中启发性决策的所有信息,直到事务管理器需要该信息。存储在稳定存储中的实际数据取决于可恢复的资源类型,未实现标准化。您可以对数据进行解析,并可能编辑资源以解决任何数据完整性问题。
Heuristic 结果存储在服务器日志中,可通过资源管理器和事务管理器识别。
手动提交或回滚事务
通常,您无法手动提交或回滚事务。从 JBoss EAP 事务管理的角度来看,您可以将事务移回待定列表中,以进行自动恢复,再次尝试或删除记录。例如:
您可以使用 read-resource 操作来检查事务中参与者的状态:
/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=2:read-resource
/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=2:read-resource
结果类似如下:
此处显示的结果状态是 HEURISTIC_HAZARD 状态,可进行恢复。
恢复 HEURISTIC_HAZARD 例外
以下步骤演示了如何恢复 类型 启发式结果的示例。
要开始恢复,您必须咨询每个资源管理器,并确定从事务管理器工具中识别的各种分支的结果。但是,您不应该强制资源管理器提交或回滚。您必须检查资源管理器,以了解启发性异常的状态。
以下是用于列出和解决各种资源管理器的启发性结果的参考链接:
注意这些链接仅供参考,可能随时更改。有关详细信息,请参阅供应商文档。
您必须执行恢复操作,如下例所示:
/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=2:recover
/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=2:recoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
恢复操作会更改事务到PREPARE的状态,并通过代表提交操作来触发恢复尝试。如果恢复尝试成功,则参与者将从交易日志中移除。您可以通过对
log-store元素再次运行探测操作来验证这一点。不应再列出参与者。如果这是最后一个参与者,则交易也将被删除。
恢复 HEURISTIC_ROLLBACK 和 HEURISTIC_COMMIT 概念
如果启发式结果是 回滚 类型,则:
- 如果资源管理器已正确实施,则该资源应该无法提交事务。
- 您必须确定是否使用忘记调用从资源管理器中删除分支,以便事务的其余部分可以正常提交并从交易存储中清理。
- 如果您没有从资源管理器中删除分支,则事务将永远保留在事务存储中。
另一方面,如果启发式结果是 提交 类型,则必须使用业务语义来处理不一致的结果。
手动协调失败的更多操作
您可以检查数据库事务表,该表是 Oracle 的 DBA_2PC_PENDING 表。但是,它们将取决于特定的资源管理器。事务管理器可以提供要在每个资源管理器中检查的分支。
有关详细信息,您应该查阅供应商在此资源管理器上的文档。如果您怀疑问题是由第三方资源经理造成的,您必须考虑向供应商提交支持问题单。
更新于 2024-02-08