1 Background introduction
An exception is thrown in the transaction template. The update operation before the exception is thrown is successful, but the transaction is not rolled back successfully, and the business data is still dropped into the db. Debug the code and find that the derivedConnectionMap in the GenericConnectionContext class is empty, causing the rollback code to not be executed.
2 solutions
Ensure that the data sources involved in all DAO operations within the transaction and the data sources associated with the transaction template are the same object. The bundles are all Spring context isolated, and the DAO and transaction templates also need to be in the same bundle.
It should be noted that the data source where the transaction template is created is the same as the data source corresponding to dao. If not, a new transaction template needs to be rebuilt.
3 More basics
Five Transaction Isolation
3.1** ISOLATION_DEFAULT: Default Isolation Level**
This is the default isolation level of PlatfromTransactionManager, using the default transaction isolation level of the database,
**oracle's default is.:READ_COMMITTED**,
**mysql's default is: REPEATABLE_READ **
The other four correspond to the isolation levels of JDBC;
3.2** **ISOLATION_READ_UNCOMMITTED: Read uncommitted.
This is the lowest isolation level for a transaction. It allows other transactions to see the uncommitted data of this transaction.
This isolation level will produce dirty reads, non-repeatable reads and phantom reads.
3.3** ****ISOLATION_READ_COMMITTED: Read Committed**
ensures that the data modified by one transaction can only be read by another transaction after it is submitted. Another transaction cannot read the uncommitted data of this transaction.
This transaction isolation level can avoid dirty reads, but non-repeatable reads and phantom reads may occur.
3.4** ****ISOLATION_REPEATABLE_READ: Repeatable Read**
This transaction isolation level can prevent dirty reads and non-repeatable reads. However, phantom reads may occur.
In addition to ensuring that one transaction cannot read uncommitted data of another transaction, it also ensures to avoid the following situation (non-repeatable read).
3.5** ****ISOLATION_SERIALIZABLE: Serialization**
This is the most expensive but most reliable transaction isolation level. Transactions are processed as sequential execution.
In addition to preventing dirty reads and non-repeatable reads, phantom reads are also avoided.
What is dirty read, non-repeatable read, phantom read?
Dirty read : refers to a transaction that reads the data of an uncommitted transaction
** Description: ** Transaction 1 updated the record but did not commit it. Transaction 2 read the updated row, then transaction T1 rolled back, and now T2 reads Take invalid.
Non-repeatable read : Read a certain row of data in the table within one transaction, and the results of multiple reads are different. One transaction reads the data after another transaction commits (update). **
Description: **Transaction 1 reads When recording, transaction 2 updates the record and commits it. When transaction 1 reads it again, you can see the modified record of transaction 2;
Virtual reading (phantom reading) : reading data inserted by another transaction within a transaction, resulting in inconsistent reading (insert)
**Explanation:** When transaction 1 reads the record, transaction 2 adds the record and submits it, the transaction When 1 reads again, you can see the records added by transaction 2;
What is the difference between non-repeatable read and phantom read?
The focus of non-repeatable reading is modification: under the same conditions, you read the data again and find that the value is different. The
results of the two reads in a transaction are inconsistent, resulting in non-repeatable reading.
For example: In transaction 1, Mary read her salary as 1000, but the operation was not completed.
con1 = getConnection();
select salary from employee empId ="Mary";
In transaction 2, the financial staff modified Mary's salary to 2000 and submitted the transaction.
con2 = getConnection();
update employee set salary = 2000;
con2.commit();
In transaction 1, when Mary reads her salary again, the salary becomes 2000.
//con1
select salary from employee empId ="Mary";
The focus of phantom reading is to add or delete:
Under the same conditions, the number of records read out for the first time and the second time are different.
For example: there are 10 employees with a salary of 1000. Transaction 1, read all employees whose salary is 1000.
con2 = getConnection();
Insert into employee(empId,salary) values("Lili",1000);
con2.commit();
Transaction 1 again reads all employees whose salary is 1000
select * from employee where salary =1000;
A total of 11 records were read, which resulted in phantom reading.
From the overall results, it seems that both non-repeatable reads and phantom reads show inconsistent results between the two reads.
But if you look at it from a control point of view, the difference between the two is relatively large. For the former, only the records that meet the conditions need to be locked. For the latter, the records that satisfy the condition and its closeness are locked.
4 Four characteristics of affairs?
Four Characteristics of Transactions (ACID)
4.1 Atomicity
Atomicity: When operating these instructions, either all of them are executed successfully or none of them are executed. As long as one of the instructions fails to execute, all instructions fail to execute, and the data is rolled back to return to the data state before the instruction was executed.
4.2 Consistency
Consistency: The execution of a transaction converts data from one state to another, but the integrity of the entire data remains stable
4.3 Isolation
Isolation: When multiple users access the database concurrently, such as when operating the same table, the transactions opened by the database for each user cannot be interfered by the operations of other transactions. Be isolated from each other.
That is: to achieve such an effect: for any two concurrent transactions T1 and T2, from the perspective of transaction T1, T2 either ends before T1 starts, or starts after T1 ends, so that each transaction feels No other transactions are executing concurrently
4.4 Persistence
Durability (Durability): When a transaction is completed correctly, it is permanent for data changes