On the blog, we can see that "system design should focus on concurrency"ArticleAs mentioned in transaction processing for distributed heterogeneous databases, it seems that there is no way for everyone.
As we all know, after a transaction is committed, it is no longer valid to perform the roolback operation for this transaction.
Then we can catch the exception before the transaction is cmmit.
For example, there are currently two connections: one is the connection of the local SQL database, called localconnection, and the other is the connection of Oracle on the server called oracleconnection.
Currently, there are two operations on localconnection and two operations on oracleconnection. We first open two transactions ()
Try
{
.
Localcommand. executenonquery () // Localcommand is a command of localconnection.
Localcommand2.executenonquery () // Localcommand2 is a command of localconnection.
..
Oraclecommand. executenonquery () // Oraclecommand is a command of oracleconnection.
Oraclecommand2.executenonquery () // Oraclecommand2 is a command of oracleconnection.
Localconnection. Commit ();
Oracleconnection. Commit (); // Two transaction commits
} Catch
{
Localconnection. roolback ();
Oracleconnection. roolback ();//Two transaction rollback
} Final
{
Localconnection. Close ();
Oracleconnection. Close ();//Two connections close ()
}
In this case, if there is an exception, neither transaction will be committed.
I don't know if this method is correct. You are welcome to discuss it.
I implemented this method in SPL and the test passed.