管理 JBoss EAP 上的事务

Red Hat JBoss Enterprise Application Platform 7.4

对红帽 JBoss 企业应用平台交易进行故障排除的说明和信息。

Red Hat Customer Content Services

摘要

本文档为管理员提供了对 JBoss EAP 事务进行故障排除的信息。

提供有关 JBoss EAP 文档的反馈

要报告错误或改进文档,请登录到 Red Hat JIRA 帐户并提交问题。如果您没有 Red Hat Jira 帐户,则会提示您创建一个帐户。

流程

  1. 单击以下链接 以创建 ticket
  2. 请包含 文档 URL章节编号 并描述问题
  3. Summary 中输入问题的简短描述。
  4. Description 中提供问题或功能增强的详细描述。包括一个指向文档中问题的 URL。
  5. Submit 创建问题,并将问题路由到适当的文档团队。

使开源包含更多

红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。详情请查看 CTO Chris Wright 信息

第 1 章 JBoss EAP 中的事务

事务由两个或多个操作组成,它们都必须成功或全部失败。成功的结果会导致提交,失败的结果会导致回滚。在回滚中,在事务尝试提交前恢复每个成员的状态。

1.1. 事务子系统

通过 transactions 子系统,您可以配置事务管理器(TM)选项,如超时值、事务日志记录、统计收集,以及是否使用 Jakarta Transactions。事务 子系统由四个主要元素组成:

核心环境
核心环境包括 TM 接口,允许 JBoss EAP 服务器为被管理的资源控制交易边界。交易协调员负责管理与参与交易的事务对象和资源的通信。
恢复环境
JBoss EAP 事务服务的恢复环境确保系统将事务结果一致地应用于受事务影响的所有资源。即使有任何应用程序进程或托管它们的计算机崩溃或丢失网络连接,此操作也会继续。
对应环境
协调者环境定义事务的自定义属性,如默认的超时和日志记录统计信息。
对象存储
JBoss EAP 事务服务使用对象存储以持久的方式记录事务结果,从而进行故障恢复。恢复管理器将扫描对象存储和其他信息位置,以获取可能需要恢复的交易和资源。

1.2. 交易的属性

设计良好的事务的典型标准是原子性、一致、隔离和持久(ACID):

Atomic
交易的所有成员必须就提交或回滚交易做出相同的决定。
致性
事务产生一致的结果,并保留特定于应用的变量。
隔离
必须在修改之前锁定所执行的数据,以防止超出事务范围的进程修改数据。
Durable
除灾难性故障外,已提交交易的影响不会丢失。

1.3. 交易组件

事务协调员
协调者管理交易的结果。它负责确保客户端调用的 Web 服务取得一致的结果。
事务上下文
事务上下文是传播的事务的信息,它允许交易跨越多个服务。
事务参与者
参与者使用参与者模式注册交易。
事务服务
交易服务捕捉基础交易协议的模型,并与与该模型附属的参与者协作。
事务 API
事务 API 为交易处理和参与者注册提供了一个界面。

1.4. 交易管理原则

1.4.1. XA 与非 XA 事务比较

非 XA 事务仅涉及一个资源。他们没有交易协调员,单一资源可以完成所有交易工作。它们有时被称为本地交易。

XA 事务涉及多个资源。他们还有一个将交易管理器与一个或多个数据库或其它资源(如 Jakarta Messaging)协调处理经理,它们都参与过一项交易。它们被称为全局交易。

第 2 章 配置事务

2.1. 唯一节点标识符

唯一的节点标识符允许 JBoss EAP 恢复仅与指定节点标识符匹配的事务和事务状态。您可以使用 com.arjuna.ats.arjuna.nodeIdentifier 属性设置节点标识符。

2.1.1. 唯一节点标识符的重要性

运行 XA 恢复时,您必须配置 JBoss EAP 事务可以恢复的 Xid 类型。每个 Xid 都具有编码的唯一节点标识符,JBoss EAP 仅恢复与指定节点标识符匹配的事务和事务状态。

您可以使用 JTAEnvironmentBean.xaRecoveryNodes 属性配置节点标识符,该属性可以在列表中包含多个值。

警告

值为星号 "*" 会强制 JBoss EAP 恢复并可能回滚所有事务,而不考虑节点标识符。它必须谨慎使用。

com.arjuna.ats.jta.xaRecoveryNode 属性的值必须是 alphanumeric,且必须与 com.arjuna.ats.arjuna.nodeIdentifier 属性的值匹配。

2.2. 配置事务管理器

您可以使用基于 Web 的管理控制台或命令行管理 CLI 配置事务管理器。

使用管理控制台配置交易管理器

以下步骤解释了如何使用基于 Web 的管理控制台配置事务管理器:

  1. 从屏幕顶部选择 Configuration 选项卡。
  2. 如果您将 JBoss EAP 作为受管域运行,请选择要修改的所需配置文件。
  3. Subsystem 列表中,选择 Transaction 并点 View
  4. 为您要配置的设置选择适当的选项卡,例如 恢复 选项。
  5. 单击 Edit,进行必要的更改,然后单击 Save 保存 更改。

使用管理 CLI 配置交易管理器

通过使用管理 CLI,您可以使用一系列命令配置事务管理器。命令全部以单机服务器的 /subsystem=transactions 开头,受管域中 默认配置 文件的 /profile=default/subsystem=transactions/ 开头。

有关所有事务管理器配置选项的详细列表,请参阅 JBoss EAP 的事务管理器配置选项

2.3. 使用系统属性配置事务管理器

您可以使用管理控制台、管理 CLI 或系统属性来配置许多事务管理器选项。不过,以下选项只能使用系统属性进行配置。它们不能通过管理 CLI 或管理控制台进行配置。

属性名称描述

RecoveryEnvironmentBean.periodicRecoveryPeriod

恢复尝试之间的间隔,以秒为单位。

  • 必须是一个正的集成器。
  • 默认为 120 秒(2 分钟)。

RecoveryEnvironmentBean.recoveryBackoffPeriod

第一次和第二次恢复通过之间的间隔,以秒为单位。

  • 必须是一个正的集成器。
  • 默认值为 10 秒。

RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset

第一次恢复通过前间隔,以秒为单位。

  • 必须是 0 或一个正的 Integer。
  • 默认值为 0 秒。

RecoveryEnvironmentBean.expiryScanInterval

到期扫描之间的间隔,以小时为单位。

  • 可以是任何 Integer。
  • 0 禁用扫描。
  • 负值会延迟第一次运行。
  • 默认值为 12 小时。

本例演示了如何在 standalone.xml 服务器配置文件中配置这些系统属性。

<system-properties>
    <property name="RecoveryEnvironmentBean.periodicRecoveryPeriod" value="180"/>
    <property name="RecoveryEnvironmentBean.recoveryBackoffPeriod" value="20"/>
    <property name="RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset" value="5"/>
    <property name="RecoveryEnvironmentBean.expiryScanInterval" value="24"/>
</system-properties>

有关如何配置系统属性的更多信息,请参阅《 配置指南》 中的 系统属性

2.4. 配置数据源以使用 Jakarta Transactions

此任务演示了如何在数据源上启用 Jakarta Transactions。

先决条件

  • 您的数据库必须支持 Jakarta Transactions。如需更多信息,请参阅数据库厂商的文档。
注意

配置指南 中所述,XA 数据源是能够默认启用 Jakarta Transactions。

将数据源配置为使用 Jakarta Transactions

  1. 使用以下管理 CLI 命令,将 jta 属性设为 true

    /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=jta,value=true)
    注意

    在受管域中,在此命令前加上 /profile=PROFILE_NAME

  2. 重新加载服务器以使更改生效。

    reload

您的数据源现在已配置为使用 Jakarta Transactions。

2.5. 为 JTS 配置 ORB

在 JBoss EAP 的默认安装中,针对事务的对象请求代理(ORB)支持被禁用。您可以使用管理 CLI 或管理控制台,在 iiop-openjdk 子系统中配置 ORB 设置。

注意

在受管域中使用 full 或 full - ha 配置文件或 standalone- full.xml 或 standalone-full- ha.xml 配置文件时,可以使用 iiop- openjdk 子系统。

有关 iiop-openjdk 子系统的可用配置选项列表,请参阅《 配置指南中的 IIOP 子系统属性

使用管理 CLI 配置 ORB

您可以使用管理 CLI 配置 ORB 的各个方面。这是用于 JTS 的 ORB 的最小配置。

您可以使用 full 配置文件为受管域配置以下管理 CLI 命令:如有必要,请更改配置集,使其适合您需要配置的配置文件。如果您使用的是单机服务器,请省略命令的 /profile=full 部分。

启用安全拦截器

通过将值设置为 identity 来启用 security 属性。

/profile=full/subsystem=iiop-openjdk:write-attribute(name=security,value=identity)
在 IIOP 子系统中启用事务

要为 JTS 启用 ORB,请将 transactions 属性 的值设置为 full,而不是默认的 spec

/profile=full/subsystem=iiop-openjdk:write-attribute(name=transactions, value=full)
在事务子系统中启用 JTS
/profile=full/subsystem=transactions:write-attribute(name=jts,value=true)
注意

对于 JTS 激活,服务器必须重新启动,因为重新加载是不够的。

使用管理控制台配置 ORB

  1. 从管理控制台顶部选择 Configuration 选项卡。在受管域中,您必须选择要修改的适当配置文件。
  2. 选择 SubsystemsIIOP(OpenJDK) 并点击 View
  3. 单击 Edit,并根据需要修改属性。
  4. 单击 Save 以保存更改。

第 3 章 管理事务

3.1. 浏览事务

管理 CLI 支持浏览和操作事务记录的功能。此功能由 TM 与 JBoss EAP 管理 API 之间的交互来提供。

交易管理器将各项待处理交易和涉及交易的参与者的信息存储在称为对象存储的持久存储中。管理 API 将对象存储作为名为 log-store 的资源公开。探测 操作会读取事务日志,并为每个记录创建一个节点路径。您可以手动调用 探测 操作,每当您需要刷新 日志存储时。事务日志快速出现和消失是正常现象。

刷新日志存储

以下命令可在受管域中刷新服务器组的日志存储,它们使用配置文件 default :对于单机服务器,请从命令中删除 profile=default

/profile=default/subsystem=transactions/log-store=log-store:probe

查看所有准备的事务

要查看所有准备的事务,请先 刷新日志存储,然后运行以下命令,该命令的作用类似于文件系统 ls 命令:

ls /profile=default/subsystem=transactions/log-store=log-store/transactions

或者

/host=master/server=server-one/subsystem=transactions/log-store=log-store:read-children-names(child-type=transactions)

显示每项事务及其唯一标识符。单个操作可以针对单个交易运行。如需更多信息 ,请参阅管理交易

3.2. 管理事务

查看交易的属性

要查看事务的相关信息,如 Java 命名和目录接口名称、EIS 产品名称和版本或其状态,请使用 read-resource 操作。

/profile=default/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9:read-resource

查看交易参与者的详细信息

每个事务日志包含一个子元素,称为 参与者。使用此元素的 read-resource 操作来查看事务参与者的详细信息。参与者通过其 Java 命名和目录接口名称标识。

/profile=default/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=java\:\/JmsXA:read-resource

结果可能类似如下:

{
   "outcome" => "success",
   "result" => {
       "eis-product-name" => "ActiveMQ",
       "eis-product-version" => "2.0",
       "jndi-name" => "java:/JmsXA",
       "status" => "HEURISTIC",
       "type" => "/StateManager/AbstractRecord/XAResourceRecord"
   }
}

此处显示的结果状态为 HEURISTIC 状态,并有资格恢复。如需了解更多详细信息 ,请参阅恢复 交易参与者。

特殊情况下,可以在对象存储中创建孤立记录,即 XAResourceRecords,日志中没有任何对应的事务记录。例如,XA 资源已准备好,但在 TM 记录之前崩溃,域管理 API 无法访问 XA 资源。要访问这些记录,您需要将 management 选项 expose-all-logs 设置为 true。此选项不会保存在管理模型中,并且在服务器重启时恢复到 false

/profile=default/subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs, value=true)

您可以使用这一备用命令,以汇总格式显示事务参与者 ID。

/host=master/server=server-one/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9:read-children-names(child-type=participants)

删除交易参与者

每个事务日志都支持 删除 操作,从而删除代表事务的事务日志。

/profile=default/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9:delete

这也会删除交易中的所有参与者。

警告

通常,您可以将参与者的日志管理保留到恢复系统或拥有该系统的事务日志中,但当您知道这样做是安全的情况下,可以使用 删除 操作。如果是 heuristicly completed XA 资源,则会触发一个 忘记 调用,以便正确清理 XA 资源供应商日志。如果这个 忘记 调用失败,默认情况下 删除 操作仍然会成功。您可以通过将 ObjectStoreEnvironmentBean.ignoreMBeanHeuristics 系统属性设置为 false 来覆盖此行为。

恢复交易参与者

每个交易参与者都支持使用恢复操作进行 恢复

/profile=default/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=2:recover

如果交易参与者的状态是 HEURISTIC,则 恢复 操作会将状态切换到 PREPARE,并请求定期恢复过程重新播放提交。

如果提交成功,则从事务日志中移除参与者。您可以通过在 日志存储上运行 探测 操作并检查 参与者是否不再列出来进行验证。如果这是最后一个参与者,则交易也将被删除。

刷新交易参与者的状态

如果事务需要恢复,您可以使用 刷新 操作确保在尝试恢复前仍然需要恢复。

/profile=default/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=2:refresh

3.3. 查看事务统计

如果启用了事务管理器统计信息,您可以查看事务管理器处理事务的统计信息。如需有关如何启用 事务管理器 统计信息的信息,请参阅 JBoss EAP 配置指南 中的"配置交易管理器"一节。

您可以使用管理控制台或管理 CLI 查看统计信息。在管理控制台中,可以通过从 Runtime 选项卡导航到 Transaction 子系统来提供事务统计信息。在管理 CLI 中,您可以通过在 read-resource 操作中使用 include-runtime=true 来查看统计信息。例如:

/subsystem=transactions:read-resource(include-runtime=true)

下表显示了管理控制台显示每个事务统计的名称、管理 CLI 属性和描述。

表 3.1. 事务子系统统计信息

显示名称属性描述

中止

相关事务数

中止的交易数量。

应用程序故障

number-of-application-rollbacks

失败的事务数量,包括超时,其故障来源是一个应用。

平均提交时间

average-commit-time

事务提交的平均时间(以纳秒为单位),从客户端调用提交到事务管理器确定成功的时间。

已提交

已提交的事务数

提交的事务数量。

Heuristics

number-of-heuristics

处于启发状态的交易数量。

Inflight Transactions

number-of-inflight-transactions

已开始但尚未终止的交易数。

嵌套事务

number-of-nested-transactions

创建的嵌套事务总数。

交易数量

事务处理次数

创建的交易总数,包括嵌套.

资源故障

number-of-resource-rollbacks

故障源自为资源失败的事务数量。

系统故障

number-of-system-rollbacks

由于内部系统错误而回滚的事务数量。

timed Out

number-of-timed-out-transactions

由于超时而回滚的事务数量。

3.4. 配置事务对象存储

事务需要存储对象的位置。对象存储的一个选项是 JDBC 数据源。如果系统性能特别值得关注,则 JDBC 对象存储可能比文件系统或 ActiveMQ 日志对象存储慢。

重要

如果 事务 子系统配置为使用 Apache ActiveMQ Artemis 日志作为事务日志的存储类型,则不允许两个 JBoss EAP 实例使用相同的目录来存储日志。应用服务器实例无法共享同一位置,各自必须为其配置唯一的位置。

注意

丢失事务对象存储可能会导致数据一致性丢失。因此,对象存储需要置于 安全 驱动器上。

使用 JDBC 数据源作为事务对象存储

按照以下步骤,将 JDBC 数据源用作事务对象存储。

  1. 创建数据源,如 TransDS。有关非 XA 数据源的说明,请参阅 JBoss EAP 配置指南中 的创建 非 XA 数据源 小节。请注意,数据源的 JDBC 驱动程序必须以 核心模块安装,如 JBoss EAP 配置指南 中所述,而非 JAR 部署,才能使对象存储正常工作。
  1. 将数据源的 jta 属性设为 false

    /subsystem=datasources/data-source=TransDS:write-attribute(name=jta, value=false)
  2. jdbc-store-datasource 属性设置为数据源要使用的 Java 命名和目录接口名称,例如 java:jboss/datasources/TransDS

    /subsystem=transactions:write-attribute(name=jdbc-store-datasource, value=java:jboss/datasources/TransDS)
  3. use-jdbc-store 属性设为 true

    /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)
  4. 重新启动 JBoss EAP 服务器以使更改生效。

事务 JDBC 存储属性

下表列出了与 JDBC 对象存储相关的所有可用属性。

注意

此表中的属性名称会在管理模型中出现时列出,例如使用管理 CLI 时。请参阅位于 EAP_HOME/docs/schema/wildfly-txn_4_0.xsd 的架构定义文件,以查看 XML 中出现的元素,因为管理模型可能会有所不同。

表 3.2. 事务的 JDBC 存储属性

属性描述

use-jdbc-store

将它设置为 true,为事务启用 JDBC 存储。

jdbc-store-datasource

用于存储的 JDBC 数据源的 Java 命名和目录接口名称。

jdbc-action-store-drop-table

是否在启动时丢弃和重新创建操作存储表。默认值为 false

jdbc-action-store-table-prefix

操作的前缀存储表名称。

jdbc-communication-store-drop-table

是否在启动时丢弃和重新创建通信存储表。默认值为 false

jdbc-communication-store-table-prefix

通信存储表名称的前缀。

jdbc-state-store-drop-table

是否在启动时丢弃和重新创建状态存储表。默认值为 false

jdbc-state-store-table-prefix

状态存储表名称的前缀。

使用 ActiveMQ Journal 对象存储

按照以下步骤,使用 ActiveMQ 日志对象存储:

  1. use-journal-store 属性设为 true

    /subsystem=transactions:write-attribute(name=use-journal-store,value=true)
  2. 重新启动 JBoss EAP 服务器以使更改生效。

第 4 章 监控事务

4.1. 为事务子系统配置日志记录

您可以独立于 JBoss EAP 中的其他日志设置控制与事务相关的日志信息量。您可以使用管理控制台或管理 CLI 配置日志设置。

使用管理控制台配置事务日志记录器

  1. 导航到 Logging 子系统配置。

    1. 在管理控制台中,单击 Configuration 选项卡。如果使用受管域,您必须选择适当的服务器配置文件。
    2. 选择 SubsystemsLoggingConfiguration 并点 View
  2. 编辑 com.arjuna 属性。

    选择 Categories 选项卡。com.arjuna 条目已经存在。选择 com.arjuna,再单击 Edit。您可以更改日志级别,并选择是否使用父处理程序。

    • 日志级别:

      由于事务可能会产生大量日志输出,默认的日志记录级别被设置为 WARN,以便服务器日志不会被事务输出所困扰。如果您需要检查事务处理详细信息,请使用 TRACE 日志级别,以便显示事务 ID。

    • 使用父处理程序:

      父处理程序指示日志记录器是否应将输出发送到其父级日志记录器。默认行为为 true

  3. 单击 Save 以保存更改。

使用管理 CLI 配置交易日志记录器

使用以下命令,从管理 CLI 设置日志级别:对于单机服务器,请从命令中删除 /profile=default

/profile=default/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=VALUE)

4.1.1. 启用 TRACE 日志级别

TRACE 日志记录级别将数据添加到日志中,以便您可以诊断 JBoss EAP 中的 Jakarta Connectors 问题。以下流程演示了如何为 org.jboss.jca、org.jboss. as.connectorcom.arjuna 类启用 TRACE 级别日志记录。

先决条件

  • 您已安装 JBoss EAP。

流程

  1. 打开终端。
  2. 启动管理 CLI。
  3. 选择以下选项之一:

    • 在受管域中,使用以下命令为 org.jboss.jca、org.jboss. as.connectorcom.arjuna 类启用 TRACE 日志记录级别:

      /profile=<PROFILE NAME>/subsystem=logging/logger=org.jboss.jca:add(level=TRACE)
      /profile=<PROFILE NAME>/subsystem=logging/logger=org.jboss.as.connector:add(level=TRACE)
      /profile=<PROFILE NAME>/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=TRACE)

      <PROFILE NAME> 替换为您的 JBoss EAP 配置文件: defaultfull 或 full -ha

    • 如果您将 JBoss EAP 作为单机服务器运行,请使用以下命令为 org.jboss.jca、org.jboss. as.connectorcom.arjuna 类启用 TRACE 日志级别:

      /subsystem=logging/logger=org.jboss.jca:add(level=TRACE)
      /subsystem=logging/logger=org.jboss.as.connector:add(level=TRACE)
      /subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=TRACE)

      另外,使用以下命令在 console-handler 类中启用 TRACE 日志记录级别:

      /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level,value=TRACE)

      代码片段添加到适当的配置文件中:

      <logger category="com.arjuna">
        <level name="TRACE"/>
      </logger>
      
      <logger category="org.jboss.jca">
        <level name="TRACE"/>
      </logger>
      <logger category="org.jboss.as.connector">
        <level name="TRACE"/>
      </logger>

4.1.2. 启用 Transaction Bridge Logger

事务网桥是 XTS 顶部的一层,是交易管理器 Jakarta Transactions 或 JTS 组件顶部的一层。它与 JBoss EAP 服务器的其他部分交互。您可以启用与 Transaction Manager 交互的组件的详细日志记录,以详细解释系统操作。

事务网桥使用 logging 子系统。在运行 JBoss EAP 服务器时,日志是从 standalone-xts.xml 文件中的 logging 子系统配置配置的。事务网桥的日志记录可用于调试目的。

您可以使用以下管理 CLI 命令配置 org.jboss.jbossts.txbridge 日志记录器以启用事务网桥日志:

/subsystem=logging/logger=org.jboss.jbossts.txbridge:add(level=ALL)

这会在服务器配置文件中生成以下 XML:

<logger category="org.jboss.jbossts.txbridge">
  <level name="ALL" />
</logger>
注意

部署顺序问题可能会导致交易管理器组件在 记录 子系统(包括事务网桥)全面配置之前变为活动状态。在这种情况下,会在启动时应用默认的日志级别,从而导致缺少详细的调试消息。

您可以配置 com.arjuna 日志记录器,以启用详细日志记录:

/subsystem=logging/logger=com.arjuna:write-attribute(name=level,value=ALL)

这会在服务器配置文件中生成以下 XML:

<logger category="com.arjuna">
  <level name="ALL" />
</logger>

4.1.3. 事务日志消息

您可以通过对事务日志记录器使用 DEBUG 日志级别来跟踪事务状态,同时让日志文件保持可读性。如需详细调试,请使用 TRACE 日志级别。有关 配置事务日志记录器的信息,请参阅为事务子系统 配置日志记录器。

事务管理器(TM)当配置为登录 TRACE 日志级别时,可以生成大量日志信息。以下是一些最常查看的消息:此列表不全面,因此您可能会看到除这些消息以外的消息。

表 4.1. 事务状态更改

事务开始

当事务开始时,将执行 com.arjuna.ats.arjuna.coordinator.BasicAction 的方法,并在日志中显示消息 BasicAction::Begin()for action-id <transaction uid>

事务提交

当事务提交时,将执行类 com.arjuna.ats.arjuna.coordinator.BasicAction 的方法 Commit,并在日志中显示消息 BasicAction::Commit()for action-id <transaction uid>

transaction Rollback

当事务回滚时,将执行类 com.arjuna.ats.arjuna.coordinator.BasicAction 的方法 Rollback,并在日志中显示消息 BasicAction::Rollback()for action-id <transaction uid>

事务超时

当事务超时时,将执行 com.arjuna.ats.arjuna.coordinator.TransactionReaper 的方法 doCancellations,并显示在日志中以 Reaper Worker <thread id> 试图取消 <transaction uid>。然后您将看到与上方所示相同的线程回滚事务。

4.1.4. 解码交易日志文件

4.1.4.1. 查找交易的 XID/UID

javax.transaction.TransactionManager 接口提供了两种方法来定位事务标识符:

  • 您可以调用 toString 方法来打印关于事务的完整信息,包括标识符。
  • 或者,您可以将 javax.transaction.Transaction 实例转换为 com.arjuna.ats.jta.transaction.Transaction,然后调用 get_uid 方法(返回 ArjunaCore Uid 表示)或调用 getTxId 方法,它将返回 Xid 作为全局标识符,这不是分支限定符。

    com.arjuna.ats.jta.transaction.Transaction arjunaTM = (com.arjuna.ats.jta.transaction.Transaction)tx.getTransaction();
    System.out.println("Transaction UID" +arjunaTM.get_uid());

4.1.4.2. 查找事务状态和资源

TransactionStatusConnectionManager

TransactionStatusConnectionManager 对象供恢复模块用于检索事务的状态。它通过维护 TransactionStatus Connector 对象表来类似于 TransactionStatus Manager 对象的代理,每个对象都连接到应用程序 过程中的 TransactionStatusManager 对象。

您可以使用 getTransactionStatus 方法获取事务状态,该方法采用事务 Uid,如果可用,事务类型作为参数。

  1. transactions Uid 参数中的 process Uid 字段用于在事务对象存储 中查找目标 TransactionStatusManagerItem host-port 对。
  2. host-port 对用于通过使用 TransactionStatus Connector 对象建立到目标 TransactionStatus Manager 对象的 TCP 连接。
  3. TransactionStatusConnector 将事务 Uid 和事务类型传递给 TransactionStatusManager,以检索事务的状态。

以下代码示例演示了如何检索 TransactionStatusConnectionManager 并检查事务状态:

// Transaction id
Uid tx = new Uid();
. . . .
TransactionStatusConnectionManager tscm = new TransactionStatusConnectionManager();

// Check if the transaction aborted
assertEquals(tscm.getTransactionStatus(tx), ActionStatus.ABORTED);
TransactionStatusManager

TransactionStatusManager 对象充当恢复管理器的界面,从正在运行的应用进程获取事务状态。每个应用进程有一个 TransactionStatusManager 管理器,它由 com.arjuna.ats.arjuna.coordinator.TxControl 类创建。TCP 连接用于恢复管理器和 TransactionStatusManager 之间的通信。默认情况下,任何空闲端口都由 TransactionStatusManager 使用。但是,可以使用以下属性修复使用的端口:

$ EAP_HOME/bin/standalone.sh -DRecoveryEnvironmentBean.transactionStatusManagerPort=NETWORK_PORT_NUMBER
  1. 创建时,TransactionStatusManager 会作为 TransactionStatusManagerItem 获取与对象存储中的主机一起存储的端口。
  2. 启动 Listener 线程,它将等待来自 TransactionStatusConnector 的连接请求。
  3. 建立连接时,将创建一个运行 AtomicActionStatusService 服务 的连接 线程。此服务接受来自 TransactionStatusConnector 对象的事务 Uid 和事务类型(如果可用)。
  4. 事务状态从本地事务表中获取,并返回到 TransactionStatusConnector 对象。

4.1.4.3. 查看事务历史记录

默认情况下,事务服务不会维护任何关于事务的历史记录。但是,您可以将事务服务的 reconcileEnvironmentBean.enableStatistics 属性变量设置为 true,以保持有关所创建交易数量及其相应结果的信息。

您可以使用以下管理 CLI 命令启用统计信息:

/subsystem=transactions:write-attribute(name=enable-statistics,value=true)

您可以使用 com.arjuna.ats.arjuna.coordinator.TxStats 类,以编程方式获取更详细的事务统计信息。

示例: TxStats

public class TxStats
{
    /**
     * @return the number of transactions (top-level and nested) created so far.
     */

    public static int numberOfTransactions();

    /**
     * @return the number of nested (sub) transactions created so far.
     *

     public static int numberOfNestedTransactions();

     /**
     * @return the number of transactions which have terminated with heuristic
     *         outcomes.
     */

    public static int numberOfHeuristics();
    /**
     * @return the number of committed transactions.
     */

    public static int numberOfCommittedTransactions();

    /**
     * @return the total number of transactions which have rolled back.
     */

    public static int numberOfAbortedTransactions();

    /**
     * @return total number of inflight (active) transactions.
     */

    public static int numberOfInflightTransactions ();

    /**
     * @return total number of transactions rolled back due to timeout.
     */

    public static int numberOfTimedOutTransactions ();
    /**
     * @return the number of transactions rolled back by the application.
     */

    public static int numberOfApplicationRollbacks ();

    /**
     * @return number of transactions rolled back by participants.
     */

    public static int numberOfResourceRollbacks ();

    /**
     * Print the current information.
     */

    public static void printStatus(java.io.PrintWriter pw);
}

com.arjuna.ats.arjuna.coordinator.ActionManager 类使用 getNumberOfInflightTransactions 方法来提供有关当前活动事务列表的进一步信息。

第 5 章 处理事务管理器例外

5.1. 调试超时事务

交易超时的原因有很多,例如:

  • 服务器性能较慢
  • 线程卡住等待某些内容或挂起
  • 线程需要多于配置的事务超时时间来完成处理

您可以查看日志是否有以下出错信息来识别超时事务:

WARN ARJUNA012117 "TransactionReaper::check timeout for TX {0} in state {1}"

其中 {0} 是事务的 Uid,{1} 是超时事务的状态 {1} 的交易管理器视图。

事务管理器提供以下调试事务超时的选项:

  • 您可以为事务配置超时值来控制事务生命周期。如果在事务终止前超时值因提交或回滚而终止,事务 子系统 将回滚事务。
  • 您可以使用 XAResource 接口的 setTransactionTimeout 方法,将当前的事务传播到资源管理器。如果支持,此操作会覆盖与资源管理器关联的任何默认超时。在如下情况下覆盖超时功能:

    • 当长时间运行的事务有超过默认生命周期时
    • 当使用默认超时时,资源管理器可能会在事务终止前回滚,从而导致事务回滚。
  • 如果您没有指定超时值或使用 0 值,事务管理器将使用特定于实现的默认值。在 JBoss EAP 事务经理中,consultantEnvironmentBean.defaultTimeout 属性代表此实施特定默认值。默认值为 300 秒。0 代表禁用默认的事务超时。

    您可以使用以下管理 CLI 命令修改默认事务超时:

    /subsystem=transactions:write-attribute(name=default-timeout,value=VALUE)

    在受管域中运行时,您必须在命令之前使用 /profile=PROFILE_NAME指定要更新的配置集。

  • JBoss EAP 交易管理器支持全或无状态的方法,在 XAResource 实例上调用 setTransactionTimeout 方法。您可以将 JTAEnvironmentBean.xaTransactionTimeoutEnabled 属性设置为 true,这是对所有实例调用方法的默认值。否则,您可以使用 com.arjuna.ats.jta.common.JTAEnvironmentBean 类的 setXA TransactionTimeoutEnabled 方法禁用超时,并逐个事务指定超时。

5.2. 将日志迁移到新的 JBoss EAP 服务器

先决条件

确保 事务 子系统在旧版和新 JBoss EAP 之间配置完全相同。需要相同的配置,其中包含 Jakarta Transactions 数据源列表,因为任何需要恢复的日志都必须联系数据源。

5.2.1. 迁移基于文件的日志存储

要将事务管理器日志迁移到新的 JBoss EAP 服务器,您可以将日志复制到新的 JBoss EAP 服务器。

您可以使用以下命令复制基于文件的日志:

  1. 浏览到您的 EAP_HOME 目录。
  2. 使用以下命令为日志创建一个存档:

    $ tar -cf logs.tar ./standalone/data/tx-object-store
  3. 使用以下命令,将存档的日志提取到新的 EAP_HOME 目录中:

    $ tar -xf logs.tar -C NEW_EAP_HOME

5.2.2. 迁移基于 JDBC 存储的日志存储

  • 您可以将新的 JBoss EAP 服务器配置为使用旧的数据库和表,如将 JDBC 用作交易对象存储 中所述。
  • 或者,您可以确定数据库和用于事务日志的表。然后,您可以使用 SQL 工具备份表并将其恢复到新数据库。

    注意

    您可以在 JBoss EAP 随附的 h2 JAR 文件中找到 SQL 查询工具。

5.3. 在 JBoss EAP 上启用 XTS

交易管理器的 XML 事务服务(XTS)组件支持在业务交易中协调私有和公共 Web 服务。XTS 为 JBoss EAP 服务器上托管的 Web 服务提供 WS-AT 和 WS-BA 支持。它是可选的子系统,可通过 standalone-xts.xml 配置来启用。

启动启用了 XTS 的 JBoss EAP 服务器

  1. 进入 JBoss EAP 服务器目录:

    cd $EAP_HOME
  2. 将 XTS 配置文件示例复制到 /configuration 目录中:

    cp docs/examples/configs/standalone-xts.xml standalone/configuration
  3. 启动 JBoss EAP 服务器,指定 xts 配置:

    Linux:

    bin/standalone.sh --server-config=standalone-xts.xml

    Windows:

    bin\standalone.bat --server-config=standalone-xts.xml

5.4. 清除过期的事务

以下属性允许您清除过期的交易:

ExpiryEntryMonitor

当 Recovery Manager 初始化到期扫描器线程时,会创建 ExpiryEntryMonitor 对象,用于从对象存储中删除死的项目。动态加载多个扫描程序模块,这将删除特定类型的死项目。

您可以使用 RecoveryEnvironmentBean.expiryScanners 系统属性在属性文件中配置扫描程序模块。扫描程序模块是在初始化时加载的。

$ EAP_HOME/bin/standalone.sh -DRecoveryEnvironmentBean.expiryScanners=CLASSNAME1,CLASSNAME2
expiryScanInterval

所有扫描程序模块定期调用,以便通过 ExpiryEntryMonitor 线程扫描死项。您可以使用 expiryScanInterval 系统属性以小时为单位配置这个周期,如下例所示:

$ EAP_HOME/bin/standalone.sh -DRecoveryEnvironmentBean.expiryScanInterval=EXPIRY_SCAN_INTERVAL

所有扫描程序模块继承来自 ExpiryScanner 接口的相同行为。此界面提供的扫描方法由所有扫描程序模块实施,包括以下内容:扫描程序线程调用这个扫描方法。

ExpiredTransactionStatusManagerScanner

ExpiredTransactionStatusManagerScanner 从对象存储中删除死的 TransactionStatusManagerItems。这些项目在对象存储中保留在删除之前的特定时间段,默认为 12 小时。您可以使用 transactionStatusManagerExpiryTime 系统属性(以小时为单位)配置这个时间周期,如下例所示:

$ EAP_HOME/bin/standalone.sh -DRecoveryEnvironmentBean.transactionStatusManagerExpiryTime=TRANSACTION_STATUS_MANAGER_EXPIRY_TIME
AtomicActionExpiryScanner

AtomicActionExpiryScanner 可移动假定已完成 AtomicAction 的事务日志。例如,如果在告知参与者提交后发生故障,但在 事务 子系统可以更新日志之前,在恢复后 JBoss EAP 事务管理器尝试重播提交请求。此重播显然会失败,从而导致日志无法被删除。当因为损坏或零长度等原因无法自动恢复日志时,也可以使用 AtomicActionExpiryScanner。所有日志都会根据附加 /Expired 的旧位置移动到特定的位置。

注意

默认情况下禁用 AtomicActionExpiryScanner。您可以通过在事务管理器属性文件中添加它来启用它。您不需要启用它来应对损坏的日志。

5.5. 恢复 Heuristic Outcomes

当事务资源在分布式事务的完成阶段做出单边决策以提交或回滚事务更新时,会进行 heuristic completion。这可以使分布式数据处于不确定的状态。网络故障或资源超时可能是造成启发性完成的原因。启发性补全会产生以下启发性结果例外之一:

HEURISTIC_COMMIT
当交易经理决定回滚时,会引发此例外,但在某些情况下,所有资源已自行提交。在这种情况下,您不需要进行任何操作,因为已达到一致的终止。
HEURISTIC_ROLLBACK
这个例外意味着资源均已执行回滚,因为事务管理器的提交决定被延迟。与 HEURISTIC_COMMIT 类似,在这种情况下,您也不需要做任何事情,因为已达到一致的终止。
HEURISTIC_HAZARD
当有些更新的出现未知时,会出现这个例外。对于已知的对象,它们或者全部已提交,或者全部已回滚。
HEURISTIC_MIXED
这个例外发生在交易的某些部分在提交时回滚。

此流程演示了如何使用 Jakarta Transactions 处理交易的启发式结果。

  1. 事务中的启发式成果的原因是资源经理承诺可以提交或回滚,然后无法履行承诺。这可能是因为第三方组件、第三方组件和 JBoss EAP 之间的集成层或 JBoss EAP 本身存在问题。

    目前,导致启发式错误的最常见两个原因是环境中的瞬态故障,以及处理资源管理器的编码错误。

  2. 通常,如果您的环境中出现瞬态故障,您通常会在发现启发性错误前了解它。这可能是因为网络中断、硬件故障、数据库故障、电源中断或许多其他因素造成的。

    如果在压力测试期间测试环境中发现了启发性的结果,这意味着您的测试环境存在缺点。

    警告

    JBoss EAP 自动恢复出现故障时处于非修复状态的交易,但不试图恢复启发式交易。

  3. 如果您的环境中没有明显失败,或者启发式结果很容易再现,这可能是因为编码错误。您必须联系第三方供应商,以确定解决方案是否可用。

    如果您怀疑问题在 JBoss EAP 本身的交易经理中,您必须提交支持票据。

  4. 您可以使用管理 CLI 尝试手动恢复事务。有关手动恢复事务的说明,请参阅恢复交易参与者 部分。
  5. 手动解决事务结果的过程取决于故障的确切情况。根据您的环境执行以下步骤:

    1. 确定涉及哪些资源管理器。
    2. 检查事务管理器和资源管理器的状态。
    3. 在一个或多个涉及的组件中手动强制进行日志清理和数据协调。
  6. 在测试环境中,或者如果您不关注数据的完整性,请删除事务日志并重新启动 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 和 object-store -path 参数设置的值。对于文件系统日志,如标准 shadow 和 Apache ActiveMQ Artemis 日志,将使用默认的目录位置,但在使用 JDBC 对象存储时,事务日志存储在数据库中。

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

结果类似如下:

{
   "outcome" => "success",
   "result" => {
       "eis-product-name" => "ArtemisMQ",
       "eis-product-version" => "2.0",
       "jndi-name" => "java:/JmsXA",
       "status" => "HEURISTIC_HAZARD",
       "type" => "/StateManager/AbstractRecord/XAResourceRecord"
   }
}

此处显示的结果状态是 HEURISTIC_HAZARD 状态,可进行恢复。

恢复 HEURISTIC_HAZARD 例外

以下步骤演示了如何恢复 类型 启发式结果的示例。

  1. 要开始恢复,您必须咨询每个资源管理器,并确定从事务管理器工具中识别的各种分支的结果。但是,您不应该强制资源管理器提交或回滚。您必须检查资源管理器,以了解启发性异常的状态。

    以下是用于列出和解决各种资源管理器的启发性结果的参考链接:

    注意

    这些链接仅供参考,可能随时更改。有关详细信息,请参阅供应商文档。

  2. 您必须执行恢复操作,如下例所示:

    /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-b66efc2\:4f9e6f8f\:9/participants=2:recover

    运行 恢复 操作会更改事务到 PREPARE 的状态,并通过代表 提交 操作来触发恢复尝试。如果恢复尝试成功,则参与者将从交易日志中移除。

    您可以通过对 log-store 元素再次运行 探测 操作来验证这一点。不应再列出参与者。如果这是最后一个参与者,则交易也将被删除。

恢复 HEURISTIC_ROLLBACK 和 HEURISTIC_COMMIT 概念

如果启发式结果是 回滚 类型,则:

  • 如果资源管理器已正确实施,则该资源应该无法提交事务。
  • 您必须确定是否使用忘记调用从资源管理器中删除分支,以便事务的其余部分可以正常提交并从交易存储中清理。
  • 如果您没有从资源管理器中删除分支,则事务将永远保留在事务存储中。

另一方面,如果启发式结果是 提交 类型,则必须使用业务语义来处理不一致的结果。

手动协调失败的更多操作

您可以检查数据库事务表,该表是 Oracle 的 DBA_2PC_PENDING 表。但是,它们将取决于特定的资源管理器。事务管理器可以提供要在每个资源管理器中检查的分支。

有关详细信息,您应该查阅供应商在此资源管理器上的文档。如果您怀疑问题是由第三方资源经理造成的,您必须考虑向供应商提交支持问题单。





更新于 2024-02-08

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.