Transaction (ACID)
In computer terms is meant to access the database and may update the various data items a program execution unit.
Four characteristics of the transaction (ACID):
Atomicity (atomicity): the transaction is a logical unit of work database, but must be atomic unit of work, for which data modification, either all executed or all not be executed.
Consistency (consistency): Upon completion of the transaction, all data must be consistent state. In the relevant database, all rules must be applied to modify the transaction to maintain the integrity of all data
Isolation (isolation): execution of a transaction can not be affected by other firms.
And persistence (durability): Once a transaction is committed, the operation of things will be permanently stored in the DB. Even the commit operation will not be lost in case of a transaction database system encounters failure.
Five isolation levels:
DEFAULT This is a PlatfromTransactionManager default isolation level, use the default database transaction isolation level.
Uncommitted Read (read uncommited): dirty reads, non-repeatable reads, phantom reads can happen
Read Committed (read commited): avoid dirty reads. However, non-repeatable reads and phantom reads can occur
Repeatable Read (repeatable read): prevent dirty reads and non-repeatable reads but phantom reads can occur.
Serialized (serializable): Avoid reading all of the above problems.
ISOLATION_DEFAULT: This is a PlatfromTransactionManager default isolation level, use the default database transaction isolation level.
Also with four corresponding JDBC isolation level;
ISOLATION_READ_UNCOMMITTED: This is the lowest transaction isolation level, it promised not to charge a foreign transaction can see the data that uncommitted transactions. Dirty read
Scene: the end of the financial wages for everyone, to A small account made 10,000 yuan, while the transaction has not yet submitted A small accounts checked to see 10,000 yuan, he thrilled. But this time found their own financial mistake to play one more hand 0, then roll back the transaction, re-issued 1000 yuan submitted affairs, A small amount of re-checked and found that Cary 1000 yuan into the empty joy of a field.
ISOLATION_READ_COMMITTED: allows unrepeatable reads but not dirty reads. This can be "instantly shared read locks" and "exclusive write locks" to achieve. Read data transaction allows other transactions continue to access the rows of data, but write uncommitted transactions will prevent other transactions from accessing the bank, Read Committed (mainly refers to the data value changes). oracle default level
Scene: A small open account transaction checked the amount of 1,000 yuan, this time he's spent chanting maturity, Alipay automatically deducted from the account of 100 yuan (100 yuan this deduction is the operation of other things, and has been submitted), a small this time check the balance again become a 900 yuan (results occurred in a thing in two inquiries are inconsistent).
ISOLATION_REPEATABLE_READ: This transaction isolation level prevents dirty reads, non-repeatable reads. But the phantom read may occur. Magic Reading (mainly refers to the number of rows to change). Mysql default level
Scene: A small open account transaction checked the amount of 1,000 yuan, he checked his account does not transfer records, this time he's spent chanting maturity, Alipay automatically deducted 100 yuan (100 deducted from the account of the yuan is something else to operate and has been submitted), he checked the balance of which is still $ 1000, and then my wife turned 800 dollars, a check account records suddenly found the two, this time it happened phantom read)
ISOLATION_SERIALIZABLE: This is the most expensive, but the cost of the most reliable transaction isolation level. The transaction is processed as a sequential execution. Serialize everything in queues, at the same time is not allowed, very low efficiency.
The propagation of transaction:
* Ensure that the same transaction
PROPAGATION_REQUIRED support the current transaction, if it does not exist to create a new (default)
PROPAGATION_SUPPORTS support the current transaction, and if not, do not use the transaction
PROPAGATION_MANDATORY support the current transaction, if not, throw an exception
* There is no guarantee the same transaction in
PROPAGATION_REQUIRES_NEW if there is a transaction exists, suspend the current transaction and creating a new transaction
PROPAGATION_NOT_SUPPORTED running in non-transactional way, if there is a transaction, pending the current transaction
PROPAGATION_NEVER running in non-transactional way, if there is a transaction, throw an exception
PROPAGATION_NESTED If the current transaction exists, nested transactions executed
Spring transaction failure conditions
@Transactional few scenes often encountered:
@Transactional method applied to private, public void @Transactional applied to the interface method is not added, then the interface called by the ordinary method, applied to the interface method @Transactional invalid, regardless of the call following method is private or public, are added to the effective @Transactional after the interface method, the present general class called directly interface method, the method is invalid @Transactional added to the interface, this class is a common interface through the interface method invocation, the effective @Transactional added to interface methods, it is the class calls the interface method, the effective @Transactional added to the interface method, it is the private methods the class calls, effective
Spring time in a no-transaction method A calls B a default method Affairs (PROPAGATION_REQUIRED), and if you use this method to call B, Method B throws RuntimeException, this time Method B transaction is not, and will not be rolled back.
@Service
public class EmployeeService {
@Autowired
private EmployeeDao employeeDao;
public void save(){
try {
this.saveEmployee (); // here this call does not open transactions, data will be saved
}catch (Exception e){
e.printStackTrace ();
}
}
@Transactional(propagation = Propagation.PROPAGATION_REQUIRED)
// here is whether or PROPAGATION_REQUIRED PROPAGATION_REQUIRES_NEW, matters not take effect
public void saveEmployee(){
Employee employee = new Employee();
employee.setName("zhangsan");
employee.setAge("26";
employeeDao.save(employee);
throw new RuntimeException();
}
}
JDK dynamic proxy. Only when the transaction will generate a dynamic proxy called directly. Object calls returned in SpringIoC container is a proxy object instead of a real object. And this here is EmployeeService real object rather than the proxy object.
Solution:
1, in the open transaction method save, no method saveEmployee default transaction or a transaction, and the catch throw new RuntimeException Method A (); (rollbackFor When not specified, the default is a RuntimeException exception rollback), such use It is to save transaction method. (Be sure to throw new RuntimeException (); otherwise exception is the capture process, the same will not be rolled back) as follows:
@Transactional () // open affairs
public void save(){
try {
this.saveEmployee (); // call here this transaction will fail, the data will be saved
}catch (Exception e){
e.printStackTrace ();
throw new RuntimeException();
}
}
