Spring distributed transactions, using or without XA-2

Original article:

Http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html? Page = 2

1. Start Message Transaction
2. receive messages
3. Start database transactions
4. Failed to update the database!
5. Roll Back database transactions
6. Roll Back message transactions

In the preceding example, a message is sent back to the middleware after the final rollback and received by another transaction at a certain time. This is usually a good thing, otherwise you may not be able to record the failure. (The automatic retry and exception handling mechanisms are not covered in this article)

The most important feature of the above two program flows is that they are atomic and form a single logical transaction, either all succeeded or all failed.

But how can we ensure that the Program Stream is similar to the above two situations? You must use the synchronization between some transaction resources, so that if a commit is performed, all are committed, and vice versa. Because it contains multiple transaction resources, transactions are distributed. If synchronization measures are not taken, they will not be atomic. The technical and conceptual difficulties of distributed transactions are the synchronization between resources (or lack of synchronization ).

The three models discussed below are based on the Xa protocol. Since these models have been widely discussed, I will not cover too many details. Readers familiar with the Xa mode can directly jump to the shared transaction resource pattern ).
Full XA (full XA with 2 PC) with two-phase commit)

If you need 'bulletproof level' protection, such as a transaction that needs to be recovered from service interruptions or even server crashes, full XA is your only choice. In this example, the shared resource used to synchronize transactions is a special Transaction Manager used to coordinate the information of processes using the Xa protocol. In Java, from the developer's perspective, the Protocol is exposed through JTA usertransaction.

As a system interface, most developers do not know about XA capabilities. They need to know what an Xa can do, what the cost is, and how to use transaction resources. The cost comes from the two-phase commit protocol two-phase commit (2 PC). The transaction Manager uses this Protocol to ensure that all resources reach an agreement on the processing result before the transaction ends.

For spring applications, spring jtatransactionmanager and spring declarative transaction management are used to hide the technical details of underlying synchronization. The difference between Xa and XA is that you only need to configure the factory Resource: Data Source instance and application Transaction Manager. This document contains a demo application (atomikos-DB project) that demonstrates this configuration. The data source instance and Transaction Manager are only XA-or JTA-related elements.

To learn how the demo application works, run the unit test case under com. springsource. Open. DB. The multipledatasourcetests class inserts data into two data sources, and then uses the spring integration support function to roll back this transaction, as shown in List 1:

By iefreer