Summary and difference between JDBC transaction and JTA distributed transaction in Java

There are three types of Java transactions: JDBC transactions, JTA (Java transaction API) transactions, and container transactions. Common container transactions, such as spring transactions, are mainly provided by J2EE application servers. Container transactions are mostly completed based on JTA, which is a fairly complex API implementation based on JNDI. Therefore, container transactions will not be discussed in this article. This paper mainly introduces two basic transactions in J2EE development: JDBC transaction and JTA transaction.

JDBC transaction

All behaviors of JDBC, including transactions, are based on a connection. In JDBC, transactions are managed through connection objects. In JDBC, the common transaction related methods are: setautocommit, commit, rollback, etc.

Here is a simple JDBC transaction code:

The above code implements a simple transfer function. Transfer operations are controlled through transactions, either submitted or rolled back.

Advantages and disadvantages of JDBC transactions

JDBC provides the most basic support for database transaction operations using Java. Through JDBC transactions, we can put multiple SQL statements into the same transaction to ensure their acid characteristics. The main advantage of JDBC transaction is that the API is relatively simple, the most basic transaction operations can be realized, and the performance is relatively good.

However, JDBC transaction has one limitation: a JDBC transaction cannot span multiple databases!!! Therefore, if it involves multi database operations or distributed scenarios, JDBC transactions are powerless.

JTA transaction

Why JTA

Usually, JDBC transactions can solve problems such as data consistency. Since its usage is relatively simple, many people only know that there are JDBC transactions about transactions in Java, Or some people know the transactions in the framework (such as hibernate, spring), etc. However, because JDBC can not implement distributed transactions, and there are more and more distributed scenarios today, JTA transactions came into being.

If you don't encounter a scenario where JDBC transactions cannot be solved in your work, it can only be said that your projects are too small. Take e-commerce websites for example. We generally divide an e-commerce website horizontally into commodity module, order module, shopping cart module, message module, payment module, etc. Then we deploy different modules to different machines, and each module communicates through remote service call (RPC). Provide external services in a distributed system.

A payment process needs to interact with multiple modules. Each module is deployed in different machines, and the databases operated by each module are inconsistent. At this time, JDBC cannot be used to manage transactions. Let's look at a piece of code:

The above code is a simple operation of payment process, in which five services are invoked. These five services are invoked through RPC. How can JDBC ensure transaction consistency? I added @ transactional annotation to the method, but due to the use of calling distributed services, the transaction can not achieve the effect of acid.

JTA transactions are more powerful than JDBC transactions. A JTA transaction can have multiple participants, while a JDBC transaction is limited to a single database connection. Any of the following Java platform components can participate in a JTA transaction: JDBC connection, JDO PersistenceManager object, JMS queue, JMS topic, Enterprise JavaBeans (EJB), and a resource allocator compiled with J2EE connector architecture specification.

Definition of JTA

Java transaction API (JTA) is a Java enterprise application program interface that allows distributed transactions across multiple XA resources to be completed in the Java environment.

JTA and its sibling Java transaction service (JTS; Java transaction service) provide distributed transaction services for J2EE platform. However, JTA only provides an interface and does not provide a specific implementation, but is provided by the J2EE server provider according to the JTS specification. The common JTA implementations are as follows:

1. JTA implementation provided by J2EE container (JBoss)

2. Independent JTA implementation: such as jotm, atomikos These implementations can be applied in environments that do not use J2EE application servers to provide distributed transaction assurance. Such as tomcat, jetty and ordinary Java applications.

JTA provides Java transaction. UserTransaction, which defines the following methods

Here, it is worth noting that ordinary JDBC operations can not be directly converted into JTA operations by using UserTransaction. JTA has requirements for datasource, connection and resource. Only classes that meet the XA specification and implement the relevant interfaces of the XA specification can participate in JTA transactions. For the XA specification, please see the relevant introduction in another article. Here, it is mentioned that the current mainstream databases support XA specification.

To use JTA transactions, you need to have an implementation of javax sql. XADataSource 、 javax. sql. Xaconnection and javax sql. Jdbc driver for xaresource interface. A driver that implements these interfaces will be able to participate in JTA transactions. An xadatasource object is a factory of an xaconnection object. Xaconnection is a JDBC connection that participates in JTA transactions.

To use JTA transactions, you must use xadatasource to generate a database connection. The generated connection is an XA connection.

The difference between XA connection (javax. SQL. Xaconnection) and non XA connection (Java. SQL. Connection) is that XA can participate in JTA transactions and does not support automatic submission.

Example code:

The above example is a transfer operation using JTA transaction, which is relatively dependent on J2EE container and needs to obtain UserTransaction and connection through JNDI.

Standard distributed transactions

A distributed transaction includes a transaction manager and one or more resource managers. A resource manager is any type of persistent data store. The transaction manager is responsible for the communication between all transaction participants.

Is the introduction of distributed transaction more similar to the transaction management in 2pc? However, 2pc is actually an implementation of XA compliant transaction managers to coordinate multiple resource managers. I have written several articles about 2pc and 3pc. In those articles, I introduced how the transaction manager in distributed transactions coordinates the unified submission or rollback of multiple transactions. Later, I will introduce in detail the contents related to distributed transactions, including but not limited to global transactions, DTP models, flexible transactions, etc.

Advantages and disadvantages of JTA

JTA has obvious advantages, that is, it provides a distributed transaction solution, strict acid. However, the standard JTA transaction management is not commonly used in daily development because it has many disadvantages:

Implementation complexity

Normally, JTA UserTransaction needs to be obtained from JNDI. This means that if we use JTA, we need to use both JTA and JNDI. JTA itself is a cumbersome API. Usually, JTA can only be used in the application server environment, so using JTA will limit the reusability of code.

summary

There are three types of Java transactions: JDBC transaction, JTA (Java transaction API) transaction and container transaction. The transaction operation usage of JDBC is relatively simple and suitable for handling the operation of the same data source. JTA transactions are relatively complex and can be used to handle transactions across multiple databases. It is a solution to distributed transactions.

Let's briefly say here that although JTA transactions are a set of APIs provided by Java for distributed transactions, the implementations of different J2EE platforms are different and are not very convenient to use. Therefore, this more responsible API is generally not used in projects. At present, the most commonly used distributed transaction solutions in the industry mainly include asynchronous message assurance, TCC, best effort notification, etc.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.