Shulou(Shulou.com)06/01 Report--

Editor to share with you the spring transaction isolation level, propagation behavior and spring+mybatis+atomikos to achieve distributed transaction management methods, I hope you will learn a lot after reading this article, let's discuss it together!

1. The definition of transaction: a transaction is a collection of multiple operation units, and the operations of multiple units are inseparable as a whole, either unsuccessful or successful. It must follow four principles (ACID).

Atomicity (Atomicity): that is, a transaction is an indivisible minimum unit of work, with either all or none of the operations within the transaction.

Consistency (Consistency): before the execution of the transaction, the data of the database is in the correct state, but after the completion of the transaction, the data of the database should still be in the correct state, that is, the data integrity constraint has not been broken; such as bank transfer, A transfer to B, you must ensure that A's money must be transferred to B, there must be no A's money transferred but B has not received it, otherwise the data of the database will be in an inconsistent (incorrect) state.

Isolation (Isolation): concurrent transaction execution does not affect each other, and operations within one transaction do not affect other transactions, which requires the transaction isolation level to specify isolation

Durability: once a transaction executes successfully, its changes to the data in the database must be permanent and will not cause data inconsistency or loss due to system failures or power outages, for example.

two。 Type of transaction

Database is divided into local transaction and global transaction.

Local transaction: general affairs, independent of a database, can guarantee the operation of the ACID on the database.

Distributed transactions: transactions involving two or more database sources, that is, transactions that span multiple homogeneous or heterogeneous databases (consisting of local transactions of each database). Distributed transactions are designed to guarantee the ACID of all operations of these local transactions, so that transactions can span multiple databases

Java transaction types are divided into JDBC transaction and JTA transaction.

JDBC transaction: the local transaction in the database transaction mentioned above, which is controlled and managed by the connection object.

JTA transaction: JTA refers to Java transaction API (Java Transaction API), which is the Java EE database transaction specification. JTA only provides transaction management interface and is implemented by application server vendors (such as WebSphere Application Server). JTA transaction is more powerful than JDBC and supports distributed transactions.

It is divided into declarative transaction and programmatic transaction according to whether it is programmed or not, refer to http://blog.csdn.net/liaohaojian/article/details/70139151

Declarative transactions: implemented through XML configuration or annotations.

Programmatic transactions: implemented by programming code when needed in business logic, with smaller granularity.

3.Spring transaction isolation levels: spring has five isolation levels, which are defined in the TransactionDefinition interface. If you look at the source code, you can see that its default isolation_default (the default level of the underlying database), and the other four isolation levels are consistent with the database isolation level.

ISOLATION_DEFAULT: using the default isolation level of the underlying database, whatever is set by the database administrator

ISOLATION_READ_UNCOMMITTED (uncommitted read): minimum isolation level, can be read by other transactions before the transaction is committed (phantom read, dirty read, non-repeatable read)

ISOLATION_READ_COMMITTED (commit read): a transaction commits before it can be read by other transactions (this isolation level prohibits other transactions from reading data from uncommitted transactions, so it still causes phantom and non-repeatable readings), sql server default level

ISOLATION_REPEATABLE_READ (repeatable readable): it can be read repeatedly to ensure that when the same data is read multiple times, its value is the same as that at the beginning of the transaction, and it is forbidden to read uncommitted data from other transactions (this isolation basically prevents dirty reading and cannot be read repeatedly (with emphasis on modification), but there will be phantom readings (focusing on adding and deleting) (MySql default level, changes can be made through set transaction isolation level level)

ISOLATION_SERIALIZABLE (serialization): the most expensive and reliable isolation level (this isolation level prevents dirty, non-repeatable, phantom reading)

Lost update: two transactions update a row of data at the same time, and the update of the last transaction overwrites the update of the first transaction, resulting in the data loss of the first transaction update, which is caused by no locking.

Illusion: in the same transaction operation, the same data is read many times in different time periods (different transactions), and the content is inconsistent (usually the number of rows becomes more or less).

Dirty reading: dirty reading when one transaction reads the contents of another transaction that is not mentioned.

Non-repeatable reading: multiple reads in the same transaction are inconsistent (usually the number of rows is the same, but the content has changed).

The difference between phantom reading and unrepeatable reading: the focus of phantom reading is on insertion and deletion, that is, the second query will find less or more data than the first query, so as to give people an illusion, while the focus of unrepeatable reading is modification. that is, the second query will find that the query results are inconsistent with the first query, that is, the first result can not be reproduced.

The higher the database isolation level is, the higher the execution cost is, and the worse the concurrent execution ability is, so it is necessary to consider comprehensively in the actual project development and use. In order to consider the concurrency performance, the commit read isolation level is generally used, which can avoid losing updates and dirty readings. Although unrepeatable reads and phantom reads cannot be avoided, pessimistic locks or optimistic locks can be used to solve these problems where possible.

4. Propagation behavior: there are seven major propagation behaviors, which are also defined in the TransactionDefinition interface.

PROPAGATION_REQUIRED: supports the current transaction. If there is no transaction, create a new one.

PROPAGATION_SUPPORTS: supports the current transaction. If there is no transaction, the execution is non-transactional (there is a note in the source code, which is not quite clear, and is left for later study).

PROPAGATION_MANDATORY: supports the current transaction and throws an exception if there is no transaction (forcing it to be executed in an existing transaction, and business methods cannot initiate their own transactions on their own).

PROPAGATION_REQUIRES_NEW: always create a new transaction and suspend the original transaction if there is an existing one.

PROPAGATION_NOT_SUPPORTED: the current transaction is not supported and has always been executed in a non-transactional manner. If the current transaction exists, the transaction is suspended.

PROPAGATION_NEVER: the current transaction is not supported; if the current transaction exists, an exception is thrown.

PROPAGATION_NESTED: if the current transaction exists, it executes in a nested transaction, and if there is no transaction, performs an operation similar to PROPAGATION_REQUIRED (note: when applied to JDBC, only drivers above JDBC 3.0 are applicable).

5.Spring transaction support

1.spring provides many built-in transaction managers to support different data sources. There are three common categories.

Under the DataSourceTransactionManager:org.springframework.jdbc.datasource package, the data source transaction management class provides transaction management for a single javax.sql.DataSource data source, as long as it is used for JDBC,Mybatis framework transaction management.

Under the HibernateTransactionManager:org.springframework.orm.hibernate3 package, the data source transaction management class provides support for a single org.hibernate.SessionFactory transaction for transaction management when integrating the Hibernate framework. Note: this transaction manager only supports Hibernate3+ version, and Spring3.0+ version only supports Hibernate 3.2 + version.

JtaTransactionManager: located in the org.springframework.transaction.jta package, provides support for distributed transaction management, and delegates transaction management to the Java EE application server, or customize a local JTA transaction manager that is nested into the application.

The built-in transaction managers inherit the abstract class AbstractPlatformTransactionManager, while AbstractPlatformTransactionManager inherits the interface PlatformTransactionManager

The core of Spring framework supporting transaction management is transaction manager abstraction. The transaction management of multi-clock data access framework can be supported by implementing policy interface PlatformTransactionManager for different data access frameworks.

The PlatformTransactionManager interface is defined as follows

The TransactionStatus interface is defined as follows: public interface TransactionStatus extends SavepointManager {boolean isNewTransaction (); / / returns whether the current transaction is a new transaction boolean hasSavepoint (); / / returns whether the current transaction has a SavePoint void setRollbackOnly (); / / sets the transaction rollback boolean isRollbackOnly (); / / sets whether the current transaction should be rolled back void flush () / / used to refresh modifications in the underlying session to the database, generally used to refresh sessions such as Hibernate/JPA, and may have no effect on transactions such as JDBC Boolean isCompleted (); / / returns whether the transaction is completed}

2.Spring distributed transaction configuration

Refer to the JNDI data source of the application server (such as Tomcat) to indirectly implement JTA transaction management, depending on the application server

Direct integration of JOTM (official website: http://jotm.objectweb.org/) and Atomikos (official website: https://www.atomikos.com/) to provide JTA transaction management (no application server support, often used for unit testing)

Use an application server-specific transaction manager and use the advanced features of JTA transactions (Weblogic,Websphere)

1)。 Refer to the JNDI data source of the application server (such as Tomcat) to indirectly implement JTA transaction management, as follows

2) Atomikos is used to implement distributed transaction management. The configuration is as follows:

Classpath:public.properties ${db.jdbcUrlOne} ${user} ${password} ${db.jdbcUrlTwo } ${user} ${password} Org.springframework.web.servlet.view.InternalResourceView / .jsp No 105,179,90 red 200 60 80 code 4 Arial style Stylish, Microsoft Yahi has finished reading this article. I believe you have a certain understanding of spring transaction isolation level, propagation behavior and the method of spring+mybatis+atomikos to achieve distributed transaction management. If you want to know more about it, welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.