Detailed summary of transaction in Java

< H4 id = "1 what is a Java transaction" > < span style = "color: #3366ff;" > 1. What is a Java transaction?

The general idea is that transactions are only related to databases.

Transactions must comply with the acid principles established by ISO / IEC. Acid stands for Atomicity, consistency, isolation, and durability.

Atomicity of transaction: it means that any failure during transaction execution will invalidate any modification made by the transaction. Transaction consistency: when the transaction fails, all data affected by the transaction should be restored to the state before the transaction is executed. Transaction isolation: refers to the modification of data during transaction execution, which is not visible to other transactions before the transaction is committed. Transaction persistence: indicates that the status of the submitted 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 instructions are executed successfully. If there is an error in the execution of one of the instructions for some reason, all previously executed instructions will be revoked. To put it more simply: either all execution is successful, or no execution is revoked.

< H4 id = "2 - why Java transactions" > < span style = "color: #3366ff;" > 2. Why do you need Java transactions?

Transaction is proposed to solve the problem of data security operation. Transaction control is actually to control the secure access of data.

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: automatic commit and manual commit.

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

2. JTA (Java transaction API) transaction

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

JTA allows applications to perform distributed transactions -- access and update data on two or more network computer resources, which can be distributed over multiple databases. The JTA support of jdbc driver greatly enhances the data access capability.

If you plan to define transactions with JTA, 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. Xaconnections s are JDBC connections that participate in JTA transactions. You will need to set up the xadatasource with the administrative tools of the application server You can learn the relevant instructions from the documentation of the application server and jdbc driver. 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 the automatic submission function of JDBC. At the same time, applications must not call java.sql.connection.commit() or java.sql.connection.rollback on XA connections (). Instead, the application should use UserTransaction. Begin(), UserTransaction. Commit(), and sertransaction. Rollback()

3. Container transactions

Container transactions are mainly provided by J2EE application server. Container transactions are mostly completed based on JTA, which is a fairly complex API implementation based on JNDI. Relative coding enables 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, which allows us to simply specify which method to add

Once specified, the container will be responsible for transaction management tasks. This is our solution, because in this way, we can exclude the transaction code from the logical coding, and hand over all the difficulties to the J2EE container to solve. Another advantage of using EJB CMT is that programmers don't need to care about the coding of JTA API, but in theory, we must use EJB

1. The limitation of JDBC transaction control is within a database connection, but it is easy to use. 2. JTA transactions are powerful. Transactions can span multiple databases or multiple Daos, and their use is complex. 3. Container transaction mainly refers to the transaction management provided by J2EE application server, which is limited to EJB applications.

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

Auto commit transaction: each individual statement is a transaction. A commit is implied after each statement. (default) explicit transaction: start with begin transaction display and end with commit or rollback.

Java JDBC transaction mechanism

First, let's take a look at what major problems the existing JDBC operation will bring us. For example, there is a business: when we modify an information, we can query the information. It is a simple business and it is very easy to implement. However, when the business is placed on a multi-threaded and highly concurrent platform, the problem naturally arises. For example, after we perform a modification, Before executing the query, a thread also executes the modification statement. When we execute the query, the information we see may be different from that we modify. In order to solve this problem, we must introduce the JDBC transaction mechanism. In fact, the code implementation is very simple. Here is a principle implementation example for your reference:

Transaction related theory

1. Four attributes (acid) of transaction

Atomic changes to data are either all or none. Consistency: the data state is consistent before and after the transaction is executed. Isolated: the processing of one transaction cannot affect the processing of another transaction. The durable transaction ends, and its effect is persisted in the database.

2. Possible problems caused by concurrent transaction processing

Dirty read: a transaction reads the uncommitted data of another transaction. Non repeatable read: the operation of one transaction causes the other transaction to read different data twice before and after phantom read: the operation of one transaction causes the result data of the two queries of the other transaction to be different.

give an example:

When transactions a and B execute concurrently, when transaction a updates, transaction B selects and reads the uncommitted data of A. at this time, transaction a rollback, then the data read by B is invalid "dirty" data. After transaction B selects and reads the data, the update operation of transaction a changes the data selected by transaction B. at this time, transaction B reads the data again and finds that the data before and after the two times are different. After transaction B selects and reads the data, transaction a inserts or deletes a record that meets the select condition of transaction A. at this time, transaction B selects again and finds that the previous non-existent record ("phantom") is queried or a previous record is missing.

JDBC supports transactions in three aspects: 1 Auto commit mode connection provides an auto commit attribute to specify when the transaction ends. a. When auto commit is true, when the execution of each independent SQL operation is completed, the transaction will be automatically committed immediately, that is, each SQL operation is a transaction. When an independent SQL operation is completed. 123. For stored procedures or other statements that return multiple results, when all the resultset objects associated with them are closed, and all update count (the number of rows affected by update, delete and other statement operations) and output parameter (the output parameter of the stored procedure) have been obtained, the execution is regarded as completed. b. When auto commit is false, each transaction must show that the commit method is called to commit or the rollback method is called to rollback. Auto commit defaults to true. 2. Transaction isolation levels JDBC provides five different transaction isolation levels, which are defined in connection. JDBC defines five transaction isolation levels: 3 Savepoint JDBC defines the savepoint interface to provide a finer grained transaction control mechanism. When a savepoint is set, you can rollback to the state of the savepoint instead of the whole transaction. The setsavepoint and releasesavepoint methods of the connection interface can set and release savepoints. Although the JDBC specification defines the above support behaviors of transactions, the degree of support for transactions by various JDBC drivers and database manufacturers may be different. If you set it arbitrarily in the program, you may not get the desired effect. To this end, JDBC provides a databasemetadata interface and a series of methods to obtain JDBC feature support. For example, through databasemetadata Supportstranactionisolationlevel method can judge the support of transaction isolation level through databasemetadata The supportssavepoints method can determine the support for savepoints.