11.2. 事务概念

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

设计良好的事务的典型标准是原子、一致、隔离和可达(ACID)。

ACID 是缩写词，代表 原子性、一致性、隔离 和持久性。此术语通常用于数据库或事务操作。

在使用 JBoss EAP 进行事务处理方面，交易量和事务管理器 ™ 大多可以互换。交易审核员这一术语通常用于分布式 JTS 交易。

在 Jakarta Transactions 事务中，TM 在 JBoss EAP 内运行，并在两阶段提交协议期间与交易参与者通信。

TM 告知事务参与者是提交还是回滚其数据，具体取决于其他交易参与者的结果。这样，它会确保事务遵循 ACID 标准。

交易参与者是指交易中能够提交或回滚状态的任何资源。它通常是数据库或 Jakarta 消息传递代理，但通过实施交易界面，应用程序代码也可以充当交易参与者。交易的每个参与者均独立决定是否提交或回滚其状态，并且只有在所有参与者都能够提交整个交易成功时才可行。否则，每位参与者都会回滚其状态，整个交易都会失败。TM 协调提交或回滚操作，并确定事务的结果。

Jakarta Transactions 是 Jakarta EE Spec 的一部分。它在 Jakarta Transactions 1.3 规范 中定义。

Jakarta Transactions 的实施通过 TM 实施，TM 由 Narayana 项目针对 JBoss EAP 应用服务器进行介绍。TM 允许应用程序通过单一全球交易分配各种资源，如数据库或 Jakarta 消息传递代理。全局事务被称为 XA 事务。通常具有 XA 功能的资源包含在此类交易中，但非 XA 资源也可以成为全球交易的一部分。有几个优化可帮助非 XA 资源作为 XA 功能资源的行为。如需更多信息，请参阅单阶段提交LRCO 优化。

在本文档中，术语 Jakarta Transactions 指的是两个方面：

TM 在 Jakarta Transactions 事务模式中工作，数据在内存中共享，事务上下文由远程 Jakarta Enterprise Beans 调用传输。在管理事务模式中，通过发送通用对象请求代理架构(CORBA)消息和 IIOP 调用传输事务上下文来共享数据。两种模式都支持在多个 JBoss EAP 服务器之间进行事务分发。

JTS 是对象交易服务(OTS)到 Jakarta 的映射。Jakarta EE 应用使用 Jakarta Transactions 来管理事务。然后，当交易经理切换到 JTS 模式时，Jakarta Transactions 与对象事务服务事务实施交互。JTS 工作于 IIOP 协议。使用 JTS 的事务管理器使用称为对象请求代理(ORB)的进程相互通信，使用称为通用对象请求代理架构(CORBA)的通信标准。如需更多信息，请参阅 JBoss EAP 配置 指南中的 ORB 配置。

从应用角度使用 Jakarta Transactions 时，JTS 事务的行为方式与 Jakarta Transactions 交易相同。

XML 交易服务(XTS)组件支持在业务交易中协调私有和公共 Web 服务。通过使用 XTS，您可以以受控且可靠的方式协调复杂业务交易。XTS API 支持基于 WS-Coordination、WS-Atomic Transaction 和 WS-Business Activity 协议的事务协调模型。

/subsystem=xts:write-attribute(name=async-registration, value=true)

/subsystem=xts:write-attribute(name=async-registration, value=true)

XA 代表 eXtended 架构，由 X/Open Group 开发以定义使用多个后端数据存储的交易。XA 标准描述了全局 TM 和本地资源管理器之间的接口。XA 允许多个资源（如应用服务器、数据库、缓存和消息队列）参与同一事务，同时保留所有四个 ACID 属性。四个 ACID 属性中有一个是原子性，这意味着，如果其中一个参与者未能提交更改，其他参与者中止交易，并将其状态恢复为与交易发生前相同的状态。XA 资源是可参与 XA 全球交易的资源。

XA 事务是可跨越多个资源的事务。它涉及一个协调 TM，与一个或多个数据库或其他事务资源一起涉及单一全球 XA 事务。

TM 实施 X/Open XA 规范并支持跨多个 XA 资源进行 XA 事务。

XA 恢复是确保更新或回滚受交易进程影响的所有资源的过程，即使任何资源属于交易参与者崩溃或不可用。在 JBoss EAP 范围内，事务 子系统为使用它们的任何 XA 资源或子系统（如 XA 数据源、Jakarta 消息传递消息队列和 Jakarta Connectors 资源适配器）提供了 XA 恢复机制。

XA 恢复发生，无需用户干预.如果 XA 恢复失败，日志输出中会记录错误。如果需要帮助，请联系红帽全球支持服务。XA 恢复过程由定期恢复线程驱动，该线程默认每两分钟启动一次。定期恢复线程处理所有未完成事务。

XA 恢复有以下限制：

两阶段提交(2PC)协议引用一种算法来确定事务的结果。2PC 由事务管理器(TM)驱动，作为完成 XA 事务的过程。

第 1 阶段：准备

在第一阶段，交易参与者通知交易协调员是他们可以提交交易还是必须回滚。

第 2 阶段：提交

在第二阶段，交易协调员决定整个交易应提交或回滚。如果任一参与者无法提交，交易必须回滚。否则，事务可以提交。协调会指示有关要做什么的资源，他们在完成此操作时通知协调员。此时，事务已完成。

为了保持原子性并遵循用于事务的 ACID 标准，事务的某些部分可以长时间运行。事务参与者在提交时需要锁定作为队列中数据库表或消息一部分的 XA 资源。TM 需要等待每个交易参与者回听，然后才能指示他们全部提交或回滚。硬件或网络故障可能会导致资源被无限期锁定。

事务超时可以与事务关联，以控制其生命周期。如果在事务提交前通过超时阈值或回滚，超时会导致自动回滚事务。

您可以为整个事务子系统配置默认超时值，或者您可以禁用默认超时值并根据每个事务指定超时。

分布式事务是指与多个 JBoss EAP 服务器上的参与者进行的一项交易。JTS 规范要求 JTS 事务能够分布到来自不同供应商的应用程序服务器中。Jakarta Transactions 没有定义，但 JBoss EAP 支持 JBoss EAP 服务器中的分布式 Jakarta Transactions 事务。

对象请求代理(ORB)是一个向交易参与者、投资者、资源和其他跨多个应用服务器分发的其他服务发送和接收消息的过程。ORB 使用标准化接口描述语言(IDL)来通信和解释消息。通用对象请求代理架构(CORBA)是 JBoss EAP 中 ORB 使用的 IDL。

使用 ORB 的主要服务类型是分布式 Jakarta Transactions 系统，采用 JTS 规范。其他系统，特别是传统系统，可以选择使用 ORB 进行通信，而非其他机制，如远程 Jakarta Enterprise Beans 或 Jakarta 企业 Web 服务或 Jakarta RESTful Web 服务。

ORB 可移植性 API 提供了与 ORB 交互的机制。此 API 提供了获取对 ORB 引用的方法，以及将应用置于侦听来自 ORB 的传入连接的模式中。API 中的部分方法不受所有 ORB 支持。在这些情况下，会抛出异常。

API 由两个不同的类组成：

有关 ORB Portability API 中包含的方法和属性的详细信息，请参阅 红帽客户门户 上的 JBoss EAP Java 文档捆绑包。