Spring's transaction management

One: annotation-based approach

1: Configure the following in the spring integration MyBatis. xml file

1<!--transaction management in an annotation-based manner. -2<bean name= "TransactionManager"3           class= "Org.springframework.jdbc.datasource.DataSourceTransactionManager" >4<property name= "DataSource" ref= "Pooleddatasource" ></property>5</bean>6<!--proxy-target-class= "true" does not add the words will appear unsatisfied dependency expressed through field ' Accountserviceimpl ';7 The field Accountserviceimpl does not pass the dependency relationship. This error. 8This can be achieved based on the implementation of class-class receive, proxy-target-classdefault not false but to do so, you have to introduce cglib to act as an agent. 9-Ten<tx:annotation-driven transaction-manager= "TransactionManager" proxy-target-class= "true"/>

No add-Proxy-target-class throws this exception:

　　

2: Then add the annotations on the method that will be adding the transaction.

Under normal circumstances. SourceName output 1000.targetName gets 1000.

Before execution: The value of the database

After execution:

Now add the exception. A after removing 1000, throws an exception, and then B does not get 1000. A reduction of 1000.B does not add 1000 if no transaction is added.

Added after the transaction. A does not decrease. b also does not increase

Second: Transaction management based on the configuration method

1<!--Create transaction manager--2<bean name= "TransactionManager"3           class= "Org.springframework.jdbc.datasource.DataSourceTransactionManager" >4<!--to manage data sources with the transaction manager--5<property name= "DataSource" ref= "Pooleddatasource" ></property>6</bean>7<!--configuration notifications. Which methods need to be cut into what type of transaction. -8<tx:advice id= "Advice" transaction-manager= "TransactionManager" >9<tx:attributes>
This is the service Impl all methods under the implementation class are added to the transactionTen<tx:method name= "*" propagation= "REQUIRED"/> One</tx:attributes> A</tx:advice> -  -<!--to configure a facet expression and combine TX and facet expressions-- the<aop:config proxy-target-class= "true" > -<!--expressions that define which classes of a package need to be cut into a transaction, but here and there are no methods in the class that need to be cut into what kind of transaction-- -<aop:pointcut expression= "Execution (* com.ssm.service.impl.*.* (..))" id= "Pointcut"/> -<aop:advisor advice-ref= "Advice" pointcut-ref= "Pointcut"/> +</aop:config>

III: Isolation level and propagation behavior of transactions

Isolation: Transaction ISOLATION LEVEL

Level 1th: READ UNCOMMITTED (reads uncommitted content)

　　　　　　　　　　Transaction a updated a data, but did not commit. B reads the data after a update.

Level 2nd: Read Committed (reading submissions)

　　　　　　　　　　Transaction a updates a piece of data, but does not commit, and B reads the data before it is updated. Only after the commit is read is the data of the a update.

Level 3rd: Repeatable Read (can be reread)

transaction A updated a data and submitted it. However, B still cannot read the data of the a update.

Level 4th: Serializable (Serializable)

　　　　　　　　　　　Before transaction A does not commit. B is not open.

　　Propagation behavior

1, propagation_required: If there is currently no transaction, create a new transaction, if the transaction is currently present, join the transaction, this setting is the most common settings.

2, Propagation_supports: Support the current transaction, if the current transaction exists, join the transaction, if there is no current transaction, the non-transactional execution. ‘

3. Propagation_mandatory: Supports the current transaction, joins the transaction if there is a current transaction, throws an exception if there is no current transaction.

4. Propagation_requires_new: Creates a new transaction that creates a new transaction, regardless of whether the transaction is currently present.

5. Propagation_not_supported: Executes the operation in a non-transactional manner, suspending the current transaction if there is a current transaction.

6. Propagation_never: Executes in a non-transactional manner and throws an exception if a transaction is currently present.

7. propagation_nested: Executes within a nested transaction if a transaction is currently present. If there is currently no transaction, perform a similar operation as propagation_required.

1. Dirty Reads (Dirty read)--one transaction reads data that is not committed by another transaction.

In detail: When a transaction is accessing the data and modifying the data, and the modification has not yet been committed to the database, another transaction accesses the data and then uses that data. Because this data is data that has not yet been submitted, the data that is read by another transaction is dirty, and the operation based on dirty data may not be correct.

Transaction T1: Updating a single piece of data
-Transaction T2: Read record of transaction T1 update
Transaction T1: Commit is called for commit
At this point, the data read by the transaction T2 is the data stored in the database memory, called dirty data, which is called dirty reading.

Dirty reads occur when a transaction a reads a data that has been modified by another transaction B, but has not yet committed. If B is rolled back, transaction a reads invalid data. This is similar to non-repeatable reads, but the second transaction does not require a commit.

Fix dirty Read problem: Add an exclusive lock on modification, until after the transaction commits to release, read with a shared lock, read release transaction 1 read data with a shared lock (so that in the process of reading data in transaction 1, other transactions will not modify the data), do not allow any transaction operation of the data, can only read, After 1, if there is an update operation, it will be converted to an exclusive lock, other transactions are not entitled to participate in the read and write, which prevents dirty read problems. However, when the transaction 1 reads the data, it is possible that other transactions also read the data, after reading the shared lock release, the transaction 1 modifies the data, the completion of the commit transaction, the other transaction read the data again when the data is inconsistent, there will be non-repeatable read problems, so this can not avoid the non-repeatable reading problem.

2. Phantom Read (Phantom)--the same transaction, read two times with the same operation, resulting in a different number of records.

READ MORE: Phantom reading is a phenomenon that occurs when a transaction is not executed independently, such as when the first transaction modifies data in a table, which involves all rows of data in the table. At the same time, the second transaction modifies the data in the table by inserting a new row of data into the table. Then the user who will be working on the first transaction in the future finds that there are no modified rows of data in the table, as if the illusion had occurred.

Transaction T1: Querying all records in a table
-Transaction T2: inserting a record
-Transaction T2: Call commit for Commit
Transaction T1: Querying all records in the table again

At this point the transaction T1 two queries to the record is not the same, called Phantom Read.

Note: The focus of phantom reading is added or deleted.

Phantom reads occur when two identical queries are executed, and the result set returned by the second query is not the same as the first query.

What happens: There is no range lock.

How to avoid: Implementing a serialization isolation mode can occur in any low-level isolation.

Solve the Phantom reading problem: the use of the range lock RangeS ranges_s mode, lock the search scope is read-only, so as to avoid the Phantom reading problem.

3. Non-repeatable read (nonrepeatable Read)--Reads the same data two times in the same transaction, resulting in different content.

Transaction T1: Querying a record
-Transaction T2: Update records for transaction T1 queries
-Transaction T2: Call commit for Commit
Transaction T1: Querying the last record again

At this point the transaction T1 the same data two times, can get different content, called non-repeatable read.

Note: The emphasis on non-repeatable reading is modified.

In a lock-based parallel control approach, non-repeatable read problems occur if you do not add read locks when you execute a SELECT.

In a multi-version parallel control mechanism, a non-repeatable read problem occurs when a transaction that encounters a commit conflict needs to be rolled back but is released.

There are two strategies to prevent this problem from happening:

(1) Defer execution of transaction 2 until transaction 1 commits or rolls back. This policy is applied when locks are used.

(2) in multi-version parallel control, transaction 2 can be committed first, and transaction 1 continues to execute on older versions of the data. When transaction 1 finally attempts to commit, the database verifies that its results are the same as for transaction 1 and Transaction 2 order execution. If it is, transaction 1 commits successfully, and if not, transaction 1 is rolled back.

Resolving non-repeatable read problems: Sharing locks when reading data, and exclusive locks when writing data, all of which are release locks by transaction commits. The data is not allowed to be modified when read, no matter how many times the data is read in the transaction, the data is consistent and avoids the non-repeatable reading problem.
4. Missing Updates (Lost update)

The transaction T1 reads the data, performs some operations, and then updates the data. Transaction T2 Do the same thing, T1 and T2 may overwrite each other's updates when updating the data, causing an error.

5. To address the above isolation level, use the following methods:

There are five levels of transaction isolation:
(1) Transaction_none does not use transactions.
(2) transaction_read_uncommitted allow dirty reading.
(3) transaction_read_committed prevents dirty reads, the most common isolation level, and is the default isolation level for most databases.
(4) Transaction_repeatable_read can prevent dirty reading and non-repeatable reading.
(5) Transaction_serializable can prevent dirty reads, non-repeatable reads, and Phantom reads (transactional serialization) to reduce the efficiency of the database.

The five transaction isolation levels above are static constants that are defined in the connection interface, and the transaction isolation level can be set using the settransactionisolation (int levels) method.

such as: Con.settransactionisolation (Connection.repeatable_read).

Note: The isolation level of a transaction is limited by the database, and the isolation levels supported by different databases are not necessarily the same.

Spring's transaction management