X/Open CAE XA规范：分布式事务处理详解

需积分: 11 139 浏览量更新于2024-07-16 收藏 247KB PDF 举报

《分布式事务处理：X/Open CAE 规范》在现代IT系统中，分布式事务处理（Distributed Transaction Processing, DTP）是一种关键的特性，它确保在分布式环境下对多个数据源进行操作时的一致性和完整性。X/Open CAE（previously known as X/Open Company Ltd.）制定的X/Open Distributed Transaction Processing Specification，即XA规范，是业界广泛采用的标准，为Java事务API（如Java Transaction API, JTA）、MySQL的XA协议以及其他数据库管理系统提供了一致性保障。 X/Open CAE的XA规范是在1991年发布的，它定义了如何在分布式环境中协调跨多个资源（如数据库、消息队列或文件系统）的事务行为。这个标准的核心概念包括： 1. **资源管理器（Resource Manager, RM）**：每个参与事务处理的资源都由一个RM管理，负责本地事务的生命周期管理以及与全局事务协调者（Global Transaction Manager, GTM）的交互。 2. **全局事务管理器（Global Transaction Manager, GTM）**：负责协调整个分布式事务的执行，确保事务的原子性、一致性、隔离性和持久性（ACID）属性。GTM维护事务的生命周期，并在各个RM之间进行通信。 3. **两阶段提交（Two-Phase Commit, 2PC）**：这是XA规范的核心机制，分为两个阶段：预提交（Prepare）和提交（Commit）。预提交阶段，GTM通知所有RM准备提交事务；在确认所有RM都准备好后，进入提交阶段，GTM通知RM执行事务提交或回滚。 4. **故障恢复和补偿**：X/Open CAE规范定义了如何处理网络故障或RM故障，确保在异常情况下事务能够被正确地回滚或重新提交。 5. **资源适配器（Resource Adapter）**：不同的数据库系统可能需要特定的适配器来实现X/Open CAE规范，这些适配器使得各种资源可以遵循统一的接口和协议进行事务管理。使用Java事务API（JTA）时，应用开发者可以利用容器（如Spring或Java EE）提供的支持，通过 xaDataSource来连接到支持XA规范的数据库，从而实现分布式事务的管理。例如，Atomikos是一个流行的开源JTA实现，它提供了对XA规范的支持，使得开发人员可以在异构环境中无缝地处理分布式事务。 X/Open CAE的XA规范为分布式环境中的事务管理提供了一套标准化的方法论，对于那些需要处理分布式事务的系统来说，理解和掌握这个规范至关重要，它确保了在复杂的分布式应用场景中数据的一致性和可靠性。

Chapter 2

Model and Deﬁnitions

This chapter discusses the XA interface in general terms and provides necessary

background material for the rest of the speciﬁcation. The chapter shows the

relationship of the interface to the X/Open DTP model. The chapter also states the

design assumptions that the interface uses and shows how the interface addresses

common DTP concepts.

2.1 X/Open DTP Model

The ﬁgure below illustrates a local instance of a DTP system where an AP calls a TM to

structure transactions. The boxes indicate software components in the X/Open DTP

model (see the deﬁnitions in Section 2.2 on page 4). The arrows indicate the directions

in which control ﬂows.

There may be several DTP systems coexisting on the same processor. The boxes in the

ﬁgure below are not necessarily separate processes, nor necessarily a single thread of

control (see Section 2.2.8 on page 6). Furthermore, the components of this model do not

have invariable roles. For example, an RM might use the TX interface to do work in

support of a transaction.

(3) TM and RMs exchange transaction information

(2) AP deﬁnes

transaction

boundaries

through the

TX interface

Resource

Managers

(RMs)

Transaction

Manager

(TM)

Application Program (AP)

(1) AP uses

resources from

a set of RMs

2.1.1 Interfaces between Local TP Components

The subject of this X/Open speciﬁcation is interface (3) in the diagram above, the XA

interface by which TMs and RMs interact.

For more details on this model and diagram, including detailed deﬁnitions of each

component, see the referenced DTP guide.

Distributed Transaction Processing: The XA Speciﬁcation 3

Deﬁnitions Model and Deﬁnitions

2.2 Deﬁnitions

For additional deﬁnitions see the referenced DTP guide.

2.2.1 Transaction

A transaction is a complete unit of work. It may comprise many computational tasks,

which may include user interface, data retrieval, and communications. A typical

transaction modiﬁes shared resources. (The referenced OSI DTP speciﬁcation (model)

deﬁnes transactions more precisely.)

Transactions must be able to be rolled back. A human user may roll back the transaction

in response to a real-world event, such as a customer decision. A program can elect to

roll back a transaction. For example, account number veriﬁcation may fail or the

account may fail a test of its balance. Transactions also roll back if a component of the

system fails, keeping it from retrieving, communicating, or storing data. Every DTP

software component subject to transaction control must be able to undo its work in a

transaction that is rolled back at any time.

When the system determines that a transaction can complete without failure of any

kind, it commits the transaction. This means that changes to shared resources take

permanent effect. Either commitment or rollback results in a consistent state.

Completion means either commitment or rollback.

2.2.2 Distributed Transaction Processing

Within the scope of this document, DTP systems are those where work in support of a

single transaction may occur across RMs. This has several implications:

• The system must have a way to refer to a transaction that encompasses all work

done anywhere in the system.

• The decision to commit or roll back a transaction must consider the status of work

done anywhere on behalf of the transaction. The decision must have uniform effect

throughout the DTP system.

Even though an RM may have an X/Open-compliant interface, such as Structured

Query Language (SQL), it must also address these two items to be useful in the DTP

environment.

2.2.3 Application Program

The AP deﬁnes transactions and accesses resources within transaction boundaries.

Each AP speciﬁes a sequence of operations that involves resources such as terminals

and databases. This speciﬁcation generally uses the term AP to refer to a single

instance of an application program.

X/Open CAE Speciﬁcation (1991)

Model and Deﬁnitions Deﬁnitions

2.2.4 Resource Manager

An RM manages a certain part of the computer’s shared resources. Many other

software entities can request access to the resource from time to time, using services

that the RM provides. Here are some examples of RMs:

• A database management system (DBMS) is an RM. Typical DBMSs are capable of

deﬁning transactions and committing work atomically.

• A ﬁle access method such as the Indexed Sequential Access Method (ISAM) can be

the basis for an RM. Typically, an ISAM RM must be enhanced to support

transactions as deﬁned herein.

• A print server might be implemented as an RM.

A single RM may service multiple independent resource domains. An RM instance

services one of these domains. (See also Section 3.2 on page 13.) Unless speciﬁed

otherwise, operations this speciﬁcation allows on an RM are allowed on each RM

instance.

2.2.5 Global Transactions

Every RM in the DTP environment must support transactions as described in Section

2.2.1 on page 4. Many RMs already structure their work into recoverable units.

In the DTP environment, many RMs may operate in support of the same unit of work.

This unit of work is a global transaction. For example, an AP might request updates to

several different databases. Work occurring anywhere in the system must be

committed atomically. Each RM must let the TM coordinate the RM’s recoverable

units of work that are part of a global transaction.

Commitment of an RM’s internal work depends not only on whether its own

operations can succeed, but also on operations occurring at other RMs, perhaps

remotely. If any operation fails anywhere, every participating RM must roll back all

operations it did on behalf of the global transaction. A given RM is typically unaware

of the work that other RMs are doing. A TM informs each RM of the existence, and

directs the completion, of global transactions. An RM is responsible for mapping its

recoverable units of work to the global transaction.

2.2.6 Transaction Branches

A global transaction has one or more transaction branches (or branches). A branch is a

part of the work in support of a global transaction for which the TM and the RM

engage in a separate but coordinated transaction commitment protocol (see Section 2.3

on page 8). Each of the RM’s internal units of work in support of a global transaction is

part of exactly one branch.

A global transaction might have more than one branch when, for example, the AP uses

multiple processes or is involved in the same global transaction by multiple remote

APs.

After the TM begins the transaction commitment protocol, the RM receives no

additional work to do on that transaction branch. The RM may receive additional work

Distributed Transaction Processing: The XA Speciﬁcation 5

Deﬁnitions Model and Deﬁnitions

on behalf of the same transaction, from different branches. The different branches are

related in that they must be completed atomically.

Each transaction branch identiﬁer (or XID — see Section 4.2 on page 19) that the TM

gives the RM identiﬁes both a global transaction and a speciﬁc branch. The RM may

use this information to optimise its use of shared resources and locks.

2.2.7 Transaction Manager

TMs manage global transactions, coordinate the decision to commit them or roll them

back, and coordinate failure recovery. The AP deﬁnes the start and end of a global

transaction by calling a TM. The TM assigns an identiﬁer to the global transaction (see

Section 4.2 on page 19). The TM manages global transactions and informs each RM of

the XID on behalf of which the RM is doing work. Although RMs can manage their

own recoverable work units as they see ﬁt, each RM must accept XIDs and associate

them with those work units. In this way, an RM knows what recoverable work units to

complete when the TM completes a global transaction.

2.2.8 Thread of Control

A thread of control (or a thread) is the entity, with all its context, that is currently in

control of a processor. A thread of control is an operating-system process: an address

space and single thread of control that executes within that address space, and its

required system resources. The context may include the process’ locks on shared

resources, and the ﬁles the process has open. For portability reasons, the notion of

thread of control must be common among the AP, TM and RM.

The thread concept is central to the TM’s coordination of RMs. APs call RMs to request

work, while TMs call RMs to delineate transaction branches. The way the RM knows

that a given work request pertains to a given branch is that the AP and the TM both call

it from the same thread of control. For example, an AP thread calls the TM to declare the

start of a global transaction. The TM records this fact and informs RMs. After the AP

regains control, it uses the native interface of one or more RMs to do work. The RM

receives the calls from the AP and TM in the same thread of control.

Certain XA routines, therefore, must be called from a particular thread. The reference

manual pages in Chapter 5 indicate which routines require this.

2.2.9 Tightly- and Loosely-coupled Threads

Many application threads of control can participate in a single global transaction. All

the work done in these threads is atomically completed. Within a single global

transaction, the relationship between any pair of participating threads is either tightly-

coupled or loosely-coupled:

• A tightly-coupled relationship is one where a pair of threads are designed to share

resources. In addition, with respect to an RM’s isolation policies, the pair are

treated as a single entity. Thus, for a pair of tightly-coupled threads, the RM must

guarantee that resource deadlock does not occur within the transaction branch.

X/Open CAE Speciﬁcation (1991)

剩余93页未读，继续阅读

火柴头9527

粉丝: 25
资源: 5

X/Open CAE XA规范：分布式事务处理详解

Distributed Transaction Processing The XA Specification

无法启动DISTRIBUTED TRANSACTION COORDINATOR解决方法

Spring Cloud Alibaba

torch.distributed.elastic.multiprocessing.errors.ChildFailedError

torch.distributed.elastic.multiprocessing.errors.childfailederror:

torch.distributed.

How to use atomikos

seata springboot

coflow scheduling frameworks

torch.distributed.elastic.multiprocessing.errors.childfailederror

最新资源