The principle and application of in-depth Java transaction

1. What is a JAVA transaction? The

  usual concept is that transactions are only related to databases.

  Transactions must obey the ACID principles established by ISO/IEC. ACID is an acronym for atomicity, consistency, isolation and durability. The atomicity of a transaction means that any failure in the execution of the transaction will invalidate any modifications made by the transaction. Consistency means that when a transaction fails, all data affected by the transaction should be restored to the state before the transaction. Isolation means that modifications to data during transaction execution are not visible to other transactions until the transaction commits. Persistence means that the state of the committed data should be correct when the transaction fails.

  Generally speaking, a transaction is a group of atomic operation units. From the database point of view, it is a group of SQL instructions. Either all of them are executed successfully. If one of the instructions is executed incorrectly for some reason, all the previously executed instructions will be undone. To put it more simply: either all executions are successful, or undo is not executed.
  Since the concept of a transaction comes from a database, what is a Java transaction? What is the connection between?

  In fact, if a Java application system wants to operate the database, it is realized through JDBC. Adding, modifying, and deleting are achieved indirectly through corresponding methods, and the control of the transaction is also transferred to the Java program code accordingly. Therefore, transactions for database operations are conventionally referred to as Java transactions.

  2. Why do you need Java transactions

  Transaction is proposed to solve the security operation of data, and transaction control is actually to control the security access of data. Take a simple example: For example, in bank transfer business, account A needs to transfer 1,000 yuan from its own account to account B. The balance of account A needs to be deducted by 1,000 yuan, and then account B needs to increase by 1,000 yuan. If there is a problem in the intermediate network, the deduction of 1,000 yuan from account A has ended, and the operation of B fails due to network interruption, then the entire business fails, and control must be made to require account A to cancel the transfer business. This can ensure the correctness of the business. To complete this operation, a transaction is required. If the funds in the A account are reduced and the funds in the B account are increased into one transaction, either all the operations are executed successfully, or all the operations are cancelled, thus maintaining the security of the data.

  3. Types of

  Java Transactions There are three types of Java transactions: JDBC transactions, JTA (Java Transaction API) transactions, and container transactions.

  1. JDBC transaction

  JDBC transaction is controlled by Connection object. The JDBC Connection interface ( java.sql.Connection ) provides two transaction modes: autocommit and manual commit. java.sql.Connection provides the following methods for controlling transactions:

  public void setAutoCommit(boolean)

  public boolean getAutoCommit()

  public void commit()

  public void rollback()

  When using JDBC transaction demarcation, you can combine multiple SQL statements into one in business. One disadvantage of JDBC transactions is that the scope of the transaction is limited to a database connection. A JDBC transaction cannot span multiple databases.

  2. JTA (Java Transaction API) transaction

  JTA is a high-level, implementation-independent, protocol-independent API that applications and application servers can use to access transactions.

  JTA allows applications to perform distributed transactions - accessing and updating data on two or more network computer resources, which can be distributed across multiple databases. The JTA support of the JDBC driver greatly enhances data access capabilities.

  If you plan to use JTA to delimit transactions, you will need a JDBC driver that implements the javax.sql.XADataSource, javax.sql.XAConnection, and javax.sql.XAResource interfaces. A driver that implements these interfaces will be able to participate in JTA transactions. An XADataSource object is a factory for XAConnection objects. XAConnection s are JDBC connections that participate in JTA transactions.

  You will need to set up the XADataSource with the application server's administration tools. Instructions can be found in the application server and JDBC driver documentation.

  J2EE applications use JNDI to query data sources. Once the application finds the data source object, it calls javax.sql.DataSource.getConnection() to obtain a connection to the database.

 XA connections are different from non-XA connections. It is important to remember that XA connections participate in JTA transactions. This means that XA connections do not support JDBC's autocommit feature. Also, applications MUST NOT call java.sql.Connection.commit() or java.sql.Connection.rollback() on XA connections.

  Instead, applications should use UserTransaction.begin(), UserTransaction.commit(), and serTransaction. rollback() .

  3. Container transaction

  Container transaction is mainly provided by J2EE application server. Most of the container transaction is completed based on JTA, which is a JNDI-based, quite complex API implementation. Relative coding to achieve JTA transaction management, we can complete the same function through the container transaction management mechanism (CMT) provided by the EJB container, which is provided by the J2EE application server. This allows us to simply specify which method to add to the transaction, and once specified, the container will take care of the transaction management tasks. This is our civil solution, because in this way we can exclude transaction code from logical coding, while leaving all the difficulties to the J2EE container to solve. Another advantage of using EJB CMT is that the programmer does not need to care about the coding of the JTA API. However, in theory, we must use EJB.

  Four, three Java transaction differences

  1. The limitation of JDBC transaction control is within a database connection, but its use Simple.

  2. JTA transactions are powerful, transactions can span multiple databases or multiple DAOs, and the use is more complicated.

  3. Container transaction mainly refers to the transaction management provided by the J2EE application server, which is limited to the use of EJB applications.

  V. Summary

  Java transaction control is an indispensable part of building J2EE applications, and it is very important for the entire application system to choose which transaction to apply. Generally speaking, JDBC transaction can be selected in the case of a single JDBC connection connection. In the case of multiple connections or databases, JTA transaction needs to be selected. If EJB is used, EJB container transaction can be considered.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326966298&siteId=291194637