The eXtended Architecture (XA) standard is a specification released in 1991 by X/Open. XA ensures the atomicity of global transactions in heterogeneous systems.
DTP model
A distributed transaction processing (DTP) model defines a standard architecture that contains interactive interfaces for distributed transaction processing. An application program (AP) can access resources that are provided by multiple resource managers (RMs). Each RM is independent and can be heterogeneous. A transaction manager (TM) is responsible for the atomicity of global transactions.
The following figure shows the interaction between these modules.
In the DTP model, OceanBase Database acts as a RM responsible for managing a portion of data resources. To interact with the TM, OceanBase Database provides a set of XA protocol standard interfaces. To implement these interfaces, OceanBase Database internally has a set of subprograms that ensure the consistency of the external semantics for each XA protocol interface. The TM triggers the internal subprograms of OceanBase Database by calling the interfaces. After the subprograms finish processing, they return the results to the TM, which then proceeds with the next steps based on the returned results.
Basic concepts
Before you get started with the DTP model, you must understand the following basic concepts:
AP
An AP defines the boundaries of a global transaction and specifies the data access operations that comprise the global transaction.
RM
An RM manages a data resource that can be shared and recovered. For example, a traditional relational database management system can be used as an RM. If an error occurs, the RM can recover the data resource to a consistent state. The OceanBase Database system can be an RM.
Transaction branch
In most cases, a global transaction involves data access in multiple RMs. A global transaction that is executed in each RM can be regarded as a branch of the global transaction.
TM
The TM provides interfaces that define the boundaries of transactions, and is responsible for committing and recovering global transactions. If a global transaction involves multiple RMs, the TM uses the two-phase commit protocol to ensure the atomic commit of the global transaction.
Atomicity guarantee
The TM must ensure the atomicity of a global transaction in the commit phase. To this end, the TM adopts the two-phase commit protocol, which includes the following phases:
Prepare phase: The TM sends prepare requests to all RMs involved in the global transaction. After each RM receives a prepare request, the RM persists the changes made by the XA transaction branch in the RM. After the changes are persisted, the RM returns a success response to the TM. In this phase, OceanBase Database persists the redo logs of the transaction branches.
Commit or rollback phase: After the TM receives success responses from all RMs involved in the global transaction, the TM sends commit requests to the RMs. If the TM does not send commit requests, it sends rollback requests to the RMs. After the RMs receive commit or rollback requests, the RMs commit or roll back the transaction branches that correspond to the requests. In this phase, the OceanBase database persists logs for the transaction branches based on the request type. To be specific, OceanBase Database persists commit logs if commit requests are sent and persists rollback logs if rollback requests are sent. After the logs are persisted, the resources for the transaction branch are released.
Tight coupling mode
In a DTP model, multiple RMs may access the same database. In this case, multiple transaction branches of a global transaction may access the same database. If the global transaction is in tight coupling mode, multiple transaction branches that access the same database can share resources. In other words, a transaction branch can view the changes in another branch. In OceanBase Database, if two transaction branches are tightly coupled, then they share locks. To be specific, when one of the transaction branches locks a data entry, the other transaction branch considers that it locks the data entry too.
Optimization mechanism
One-phase commit
If a global transaction involves data access in only one RM, the two-phase commit mechanism is not required. To be specific, if the TM finds that a global transaction involves data access only in one RM in the commit phase, the TM can send a one-phase commit request to the RM. If the RM is OceanBase Database, the RM can directly commit the transaction branch after receiving the one-phase commit request. After the request is processed, OceanBase Database can release the resources for the transaction branch. The TM can return the result after receiving the response to the one-phase commit request without the need to send another request to the RM.
Read-only transaction branch
If an RM involved in a global transaction provides only the read service, the RM does not need to change data for the durability of the global transaction in the commit phase. After OceanBase Database receives a prepare request for a transaction branch but detects that no data is changed in that branch, it can return a special response, and then release the resources for the transaction branch. After the TM receives the special response and learns that the transaction branch is a read-only branch, the TM no longer sends two-phase commit or rollback requests to the RM.