Distributed transaction means that the participants of the transaction, the server that supports the transaction, the resource server and the transaction manager are located on different nodes in different distributed systems.
#In order to implement distributed transactions, the two-phase commit protocol introduced below needs to be used. * Phase 1: Start sending pre-commit information to all resources involved in the transaction. At this time, the resources involved in the transaction have one last chance to end the transaction abnormally. If any resource decides to end the transaction abnormally, the entire transaction is canceled and the resource will not be updated. Otherwise, the transaction will execute normally unless a catastrophic failure occurs. To prevent catastrophic failure, all resource updates are written to the log. These logs are persistent, so they survive a failure and can be updated again for all resources. * Phase 2: Occurs only when phase 1 does not end abnormally. At this point, all resource managers that can be located and individually controlled will begin performing actual data updates. In the distributed transaction two-phase commit protocol, there is a main transaction manager responsible for acting as the distributed transaction coordinator. The transaction coordinator is responsible for the entire transaction and makes it work with other transaction managers in the network. In order to implement distributed transactions, a protocol must be used to transfer transaction context information between various participants in a distributed transaction. IIOP is such a protocol. This requires that transaction participants developed by different developers must support a standard protocol to achieve distributed transactions.
The structure of a distributed transaction started in Transact-SQL is relatively simple:
1. A Transact-SQL script or application connection executes the Transact-SQL statement that starts the distributed transaction.
2. The Microsoft® SQL Server™ executing the statement becomes the master server in the transaction.
3. The script or application then performs a distributed query against the linked server, or a remote stored procedure against the remote server.
4. When a distributed query or remote procedure call is executed, the master server will automatically call MS DTC to register the linked servers and remote servers in the distributed transaction.
5. When a script or application issues a COMMIT or ROLLBACK statement, the master SQL Server will call MS DTC to manage the two-phase commit process, or notify linked servers and remote servers to roll back their transactions.
Statements
There are very few Transact-SQL statements to control distributed transactions because most of the work is done internally by Microsoft® SQL Server™ and MS DTC. The only Transact-SQL statements required in a Transact-SQL script or application are:
●Start a distributed transaction.
●Perform distributed queries against linked servers, or perform remote procedure calls against remote servers.
●Call the standard Transact-SQL COMMIT TRANSACTION, COMMIT WORK, ROLLBACK TRANSACTION or ROLLBACK WORK statement to complete the transaction.
●For any Transact-SQL distributed transaction, the SQL Server processing the Transact-SQL script or connection will automatically call MS DTC to coordinate the commit or rollback of the transaction.
The REMOTE_PROC_TRANSACTIONS option is a compatibility option that only affects remote stored procedure calls made to remote servers defined using sp_addserver. For more information about remote stored procedures, see Remote Stored Procedure Architecture. This option does not apply to distributed queries that execute stored procedures on linked servers defined using sp_addlinkedserver. For more information about distributed queries, see Distributed Queries.
The above is the detailed content of What does distributed transaction mean?. For more information, please follow other related articles on the PHP Chinese website!