Transaction isolation level: The degree of isolation of modifications to the database by one transaction from another transaction in parallel.
When two concurrent transactions access the same row in a database table at the same time, these problems can be grouped into 5 categories:
3 types of data read problems (dirty reads, non-repeatable reads and phantom reads)
2 types of data update problems (type 1 missing updates and type 2 missing updates).
1. Fantasy read : Transaction T1 reads a statement with a specified where condition and returns a result set. At this point, transaction T2 inserts a new record, which just satisfies the where condition of T1. Then T1 is queried again using the same conditions, and the record inserted by T2 can be seen in the result set. This new record is an illusion.
2. Non-repeatable read : Transaction T1 reads a row of records, then transaction T2 modifies the record just read by T1, and then T1 queries again and finds that it is different from the record read for the first time, which is called non-repeatable read.
3. Dirty read : Transaction T1 has updated a row of records, but the modification has not been committed. This T2 reads the updated data, and then T1 performs a rollback operation to cancel the previous modification, so the row read by T2 is Invalid, that is, dirty data.
4. When the first type of lost update A transaction is revoked, the updated data of the submitted B transaction is overwritten. This kind of error can cause serious problems, as can be seen through the following account withdrawals and transfers:
The second type of lost update
A transaction overwrites the data that has been submitted by B transaction, resulting in the loss of operations performed by B transaction
Oracle Database supports two transaction isolation levels, READ COMMITTED and SERIALIZABLE. So Oracle does not support dirty reads
The default transaction isolation level defined by the SQL standard is SERIALIZABLE, but Oracle uses READ COMMITTED by default
Introduction to transaction isolation mechanism:
http://blog.csdn.net/gaogaoshan/article/details/21158949
实例测试：
http://www.cnblogs.com/fxb248/archive/2012/01/06/2314696.html
但是，真实情况下并不会出现上文中所说的延迟，这是由于数据库的多版本并发控制MVVC（Multi-Version Concurrency Control）.
mvvc的介绍：
http://m.2cto.com/database/201503/381708.html
Spring的事务隔离：
spring支持上面说的四种事务隔离机制，还有一个默认的，表示使用数据库默认的隔离机制。
具体可以参考spring相关书籍或者百度。
Spring的事务传播机制：规定了方法是否支持，以及怎么支持事务的。参考书籍或者百度。
下面文章中讲解了其中比较难区分的nested和required_new的区别。
http://m.blog.csdn.net/article/details?id=48185597