Spring transaction management

A database transaction is composed of a series of actions, which are considered as a separate unit of work. These actions are either completely executed or not executed. Transaction Management is an important part of relational data. Enterprise applications use transactions to ensure data integrity and consistency, the following four attributes can be used to describe transaction 1 atomicity. A transaction should be executed as a separate operating unit, that is, this series of operations are successfully or fail. 2. Consistency this indicates the consistency of the database's reference integrity. The table has a unique primary key. 3. isolation at the same time, multiple transactions may operate on the same dataset, each transaction should be isolated from other transactions to prevent data tampering. 4. Durability: Once the transaction is successfully executed, the transaction results must be persistent, in addition, data loss cannot be caused by system errors. A real relational database management system guarantees the above four features for each session, you can run the following SQL statement to start a session: execute multiple delete, update, and insert operations in batches using the Begin Transaction command. If all operations are executed, execute the commit operation, otherwise, perform the rollback operation. The Spring framework provides an abstraction layer on top of the transaction management API. Spring's transaction support aims to provide an optional EJB transaction by adding the transaction capability to POJO. Spring provides two types of transaction management: programmatic transactions and clear transactions. EJB requires an application server, but Spring transaction management can be implemented without the application server. Local transactions and distributed transactions local transactions are specific to a single transaction-type resource, such as JDBC connections, distributed Transactions allow you to manage transaction programming and declarative transactions across multiple transactional resources in a distributed system: You can manage transactions through programming, which provides extreme flexibility, but it is difficult to maintain. Declarative Transaction Management: You need to separate transaction management from business code. You can only manage transactions through annotations or XML-based configuration. Transaction isolation level: COMMITTED: dirty reads can be blocked, non-repeated reads and Phantom reads will occur UNCOMMITTED: dirty reads, non-repeated reads, and phantom read will occur REPEATABLE_READ dirty read and non-repeated read can be blocked, phantom read will occur SERIALIZABLE dirty read, can not be repeated read, phantom read is blocked