分布式事务处理：XA规范详解

3星 · 超过75%的资源需积分: 10 109 浏览量更新于2024-07-24 1 收藏 246KB PDF 举报

"分布式事务处理：XA规范" 《XA规范》是X/Open Company Ltd.发布的一项技术标准，专门针对分布式事务处理。该规范定义了一个接口，允许应用程序、事务管理器和资源管理器（如数据库）之间协调一致地进行分布式事务操作。分布式事务处理的关键在于确保在多个系统或网络节点上进行的操作要么全部成功，要么全部回滚，以保持数据的一致性和完整性。分布式事务处理中的“XA”代表“eXtended Architecture”，它定义了一种两阶段提交（2PC，Two-Phase Commit）协议，这是处理跨多个数据库或服务的事务的标准方法。在2PC协议中，事务分为准备阶段和提交阶段。在准备阶段，所有参与的资源管理器都会被询问是否可以提交事务；如果所有参与者都同意，那么在提交阶段，事务会被正式提交。如果有任何一方无法完成事务，整个事务将被回滚，以防止数据不一致。在《XA规范》中，详细介绍了以下几个核心概念： 1. 事务（Transaction）：一个逻辑工作单元，包含一组操作，这些操作要么全部成功，要么全部失败。 2. 事务管理器（Transaction Manager）：负责监控和控制事务的生命周期，包括开始、提交、回滚和恢复事务。 3. 资源管理器（Resource Manager）：如数据库、消息队列等，它们存储事务的状态并参与到事务的执行中。 4. 事务上下文（Transaction Context）：包含事务的唯一标识（全局事务ID，Global Transaction Identifier）和其他相关信息，用于识别和管理事务。 5. XA接口：提供给应用程序和事务管理器与资源管理器通信的接口，包括开始、结束、准备、提交和回滚事务的函数。《XA规范》不仅定义了这些概念，还详细描述了它们之间的交互过程，以及在异常情况下的恢复策略。此外，它还涵盖了对并发控制、事务隔离级别和事务属性的支持。通过遵循XA规范，开发人员能够构建高度可扩展和可靠的分布式系统，这些系统能够在各种异构环境中正确处理复杂的事务流程。这种标准化的方法使得不同的组件和服务可以无缝协作，确保了在分布式环境中的数据一致性。《XA规范》是分布式计算领域的重要里程碑，它为实现跨多个系统的强一致性和高可用性提供了基础框架。随着云计算和微服务架构的普及，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页未读，继续阅读

横云断岭

粉丝: 1290
资源: 4

分布式事务处理：XA规范详解

Distributed Transaction Processing The XA Specification

Distributed Transaction Processing-The XA+ Specification Version 2

csharp language specification v3.0 pdf

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

JDBC 3.0 Final Release: Java Data Access API Specification

JDBC 4.0技术规范详解

Java JDBC 3.0规范：数据库元数据与连接池

spring 异步编程样例

带有 python 3 和 opencv 4.1 的 Docker 映像.zip

原生js鼠标滑过文字淡入淡出效果.zip

最新资源