Original article:
Http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html? Page = 1
In spring, JTA and XA protocols are often used to implement distributed transactions. However, we also have other options. The optimal implementation depends on your application scenario, such as the type of resources used and how to balance performance, security, reliability, and data integrity. In this series of articles, David syer from springsource will explain in detail seven distributed transaction modes available for spring applications, three of which use Xa and four do not use Xa.
Level: Intermediate
Spring framework supports JTA (Java transaction application interface (Java transaction API), so that applications can use distributed transactions and XA protocols without running J2EE containers. Even so, XA is still expensive for administrators and may be unreliable or bulky. It may bring a surprise for the first time, but in the end many types of applications will avoid using it.
To help you understand various methods for implementing distributed transactions, I will analyze seven Distributed Transaction Processing modes and provide specific sample code, I will describe them one by one in terms of security and reliability, starting with the methods that maximize data integrity and Atomicity in the most common scenarios. When you read them one by one, the precautions and restrictions will increase gradually. In addition, these modes are basically arranged in descending order of operating costs (starting from the highest cost ). These modes are both architecture or technical models, rather than business models. Therefore, I will not focus on specific services, but provide brief code that explains how each mode works.
Note that Xa is used only in the first three modes, which may be inappropriate or unacceptable for performance reasons. I will not extend the discussion on the Xa mode because XA has been fully discussed in other articles, even though I provide simple DEMO code in the first mode. By reading this article, you will learn what you can do through distributed transactions, what you cannot do, and how to avoid using XA-and when you should use Xa.
Distributed transactions and atomicity
Distributed Transaction)Refers to a transaction that contains multiple transaction resources. Transaction resources refer to connectors that communicate with relational databases and message-oriented middleware. Normally, such resources provide APIs suchbegin()
,rollback()
,commit()
In Java programming, transaction resources are usually exposed as a factory product provided by the underlying platform: for databases, it is a connection generated by datasource, or Java persistence API (JPA)EntityManager
For Java Message Service (JMS), it is a session (Session)
.
In a typical use case, a JMS message triggers a database update. A successful interaction sequence is as follows:
- Start a Message Transaction
- Get message
- Start database transactions
- Update Database
- Submit database transactions
- Submit message transactions
If a database error occurs, for example, a constraint conflict occurs during an update, the ideal interaction sequence looks as follows:
By iefreer