Talking about the second distributed transaction: A distributed transaction management model based on DTC [last article]

In a previous article, we learned that what SOA really needs is a distributed transaction management system that coordinates all resources that the service operates directly (through the resources accessed by the service itself) or indirectly (through the resources accessed by the invoked service), a complex architecture. WCF, as the SOA-based distributed framework under the Windows platform, provides comprehensive support for distributed transactions. WCF, however, does not make a complete use of the Windows existing transaction control infrastructure. This section focuses on the Windows transaction processing model, first to see what roles each transaction participant plays in the model.

For all transaction participants, the following three roles are roughly the same as the functions they assume at various stages of the entire transaction lifecycle:

* Applications (application), services (service) or components (Component): Represent user programs, or services (service) or components (Component) that carry a function;

* Resource Manager (Rm:resource Manager): represents software programs for managing specific transactional resources, such as databases or queues (MSMQ);

* Transaction manager (Tm:transaction Manager): Represents a middleware program that manages the entire transaction, providing basic transaction control services for applications and resource managers.

I. Application (application), services (service) and components (Component)

Transactions are ultimately serviced by user programs, services, and components, which use the special mechanism of transactions to perform a set of related operations as an integral whole, ensuring data consistency. In the entire model, applications (services or applications, for brevity, and subsequent portions of applications, services, and components are referred to as applications) are mainly responsible for the following transaction-related tasks:

* Start a transaction: The driver of the transaction starts always applying, but not all applications start a new transaction, only the initial application is the opening of the transaction;

* (marshaling) and propagation of transactions (propagation): marshaling and disseminating the application's local transaction to another application or resource manager;

* COMMIT TRANSACTION: The opening of the transaction is also the final submitter of the transaction, and when the transaction-related operation is completed successfully, the application that initially opened the transaction commits the transaction.

Second, Resource Manager (Rm:resource Manager)

In the transaction control model, both the application and the resource manager do not directly access the specific transactional resources, but indirectly manipulate the target resources through an intermediary, which is the resource manager. According to whether the target resource can be persisted, the appropriate resource manager can be divided into the following two categories:

* Persistent Resource Manager (durable Resource manager): For managing persistent resources, such as databases and MSMQ, with Recoverability (Recovery) when transactions are rolled back;

* Volatile Resource Manager (Volatile Resource Manager): for managing volatile resources such as memory data that are not persisted, and volatile resources are not recoverable.

In the next two-phase commit (2pc:two-phase Commit) protocol for implementing distributed transactions, different registration (Enlist) approaches are used for these two different resource managers. In general, the resource manager takes several functions in the overall transaction model:

* Help the application to achieve the target resource operation;

* Register to the appropriate transaction manager, so that transaction rollback can receive recovery requests from the transaction manager to achieve the recovery of data;

* Report the results of local transactions to the corresponding transaction manager;