首先，应用级的数据管理级别与数据库的事务管理级别是不同的。比如你为了防止一项脏读操作，将读取与修改放在一个线程中，数据库依然存在丢失更新的情况。例如你想修改一个商品的销售额：
synchronized (this) {
saleObject saleObject = saleObjectRepository.findById(saleObjectId);
saleObject.setVolume(volume-1);
saleObjectRepository.save( aleObject );
}
亲测当N个用户开启多个Session同时执行操作，实际上他的销售额只是-1，而不是-N。
方法名解释：
PROPAGATION_REQUIRED -- 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS -- 支持当前事务，如果当前没有事务，就以非事务方式执行。 也是Spirngboot默认事务操作级别
ZPROPAGATION_MANDATORY -- 支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW -- 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED -- 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER -- 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED -- 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似
如果你在使用串行化事务，你可以定义两个相同作用，而不同名的方法，一个是加锁的，一个是没加锁的；以此巧妙滴适应场景要求。
事务隔离级别
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。
READ UNCOMMITTED-读未提交
Read UnCommitted事务可以读取事务已修改，但未提交的的记录。
Read UnCommitted事务会产生脏读（Dirty Read）。
Read UnCommitted事务与select语句加nolock的效果一样，它是所有隔离级别中限制最少的。
公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而singo正好去查看账户，发现工资已经到账，是5000元整，非常高兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有2000元，singo空欢喜一场。
出现上述情况，即我们所说的脏读，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。
当隔离级别设置为Read uncommitted时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。
READ COMMITTED-读提交
一旦创建共享锁的语句执行完成，该锁顶便释放。
Read Committed是SQL Server的预设隔离等级。
Read Committed只可以防止脏读。
先创建表:
CREATE TABLE tb(idint,valint) INSERT tb VALUES(1,10) INSERTtbVALUES(2,20)
然后在连接1中,执行: SET TRANS ACTION ISOLATIONLEVEL READ COMMITTED BEGIN TRANS ACTION SELECT*FROMtb;--这个SELECT结束后,就会释放掉共享锁 WAITFORDELAY'00:00:05'--模拟事务处理,等待5秒 SELECT*FROMtb;--再次SELECT tb表 ROLLBACK--回滚事务
在连接2中,执行 UPDATEtbSET val =val+10WHEREid=2;
-------- 回到连接1中.可以看到.两次SELECT的结果是不同的.
因为在默认的READ COMMITTED隔离级别下,SELECT完了.就会马上释放掉共享锁.
singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把singo工资卡的2000元转到另一账户，并在 singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有钱，扣款失败，singo十分纳闷，明明卡里有钱，为何......
出现上述情况，即我们所说的不可重复读 ，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。
当隔离级别设置为Read committed 时，避免了脏读，但是可能会造成不可重复读。
大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。
REPEATABLE READ-重复读
REPEATABLE READ事务不会产生脏读，并且在事务完成之前，任何其它事务都不能修改目前事务已读取的记录。
其它事务仍可以插入新记录，但必须符合当前事务的搜索条件——这意味着当前事务重新查询记录时，会产生幻读（Phantom Read）。
当隔离级别设置为Repeatable read 时，可以避免不可重复读。当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。
虽然Repeatable read避免了不可重复读，但还有可能出现幻读 。
singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费记录。有一天，她正在查询到singo当月信用卡的总消费金额 （select sum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction ... ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出 现了幻觉，幻读就这样产生了。
注：Mysql的默认隔离级别就是Repeatable read。
SERIALIZABLE-序列化
SERIALIZABLE可以防止除更新丢失外所有的一致性问题,即:
1.语句无法读取其它事务已修改但未提交的记录。
2.在当前事务完成之前，其它事务不能修改目前事务已读取的记录。
3.在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。
SNAPSHOT
Snapshot事务中任何语句所读取的记录，都是事务启动时的数据。
这相当于事务启动时，数据库为事务生成了一份专用“快照”。在当前事务中看到不其它事务在当前事务启动之后所进行的数据修改。
Snapshot事务不会读取记录时要求锁定，读取记录的Snapshot事务不会锁住其它事务写入记录，写入记录的事务也不会锁住Snapshot事务读取数据。