数据库事务机制：在一定程度上保证数据的一致性，并且有效提高系统性能，避免系统宕机；
在Spring中通过，数据库事务通过AOP实现，擦除了大量的try…catch…finally语句、打开关闭数据库和事务回滚提交等冗余代码；
现在介绍两种主要事务机制：
（1）一个事务相关操作必须同时成功或同时失败；——事务回滚
（2）批量操作，只需要回滚失败操作；——传播行为
Spring管理事务默认是RuntimeException或者Error，对于非运行时异常来说，可以通过设置rollbackfor（发生指定异常时回滚）、rollbackForClassName、noRollbackFor（发生指定异常时不会滚）、noRollbackForClassName来指定在什么异常的情况下依旧提交事务，在什么异常下回滚事务；例如：@Transactional(rollbackFor = Exception.class)，表示发生非运行时异常时回滚；
事务声明：@Transactional，可以注解在类或方法或接口上，注解在类上表示这个类的所有public非静态方法都将启用事务功能，推荐放在实现类上；
事务隔离级别：当同一数据被多个事务同时访问时，压制丢失更新的产生；注意只是压制，而不是消除，因为考虑到性能问题，过多的锁会导致大量线程被挂起和恢复，从而导致系统缓慢；
第一类丢失更新：操作同一数据，一个事务回滚而另一个事务操作后提交而引发数据不一致；目前大部分数据库已克服这类丢失；
第二类丢失更新：操作同一数据，多个事务同时提交而引发数据不一致；此类丢失目前有如下4中隔离级别：
（1）未提交读READ UNCOMMITTED
允许一个事务读取另一个事务未提交的数据；最低隔离，最危险，应用不大；优点是并发能力高，适合对数据一致性没有高要求而追求高并发的场景；
（2）读写提交READ COMMITTED
一个事务只能读取另外一个事务已提交数据；会出现不可重复读（针对一条记录）问题；
（3）可重复读
针对（2）中出现的不可重复读，如某个数据被一个事务读取，另一个事务再去读取只能阻塞直到前一个事务提交；会出现幻读（针对多条记录）问题；
（4）串行化SERIALIZABLE
所有SQL按照顺序执行，最高隔离；
总之，（1）可能出现脏读、不可重复读、幻读；（2）可能出现不可重复读、幻读；（3）可能出现幻读；所以使用时，要结合性能和数据一致性一起考虑，一般会以读写提交为主；Oracle只支持读写提交和串行化，默认读写提交；MySQL都支持，默认可重复读；
传播行为：方法之间调用事务采取的策略问题；一般情况下，数据库事务都是要么全部成功要么全部失败的机制，但也会出现其他情况，例如批量操作，只需要回滚失败操作即可，这就涉及到事务的传播行为；
传播行为有如下7种：
REQUIRED(TransactionDefinition.PROPAGATION_REQUIRED)：需要事务，默认，如当前存在事务，就沿用，否则新建一个事务运行子方法；
SUPPORTS(TransactionDefinition.PROPAGATION_SUPPORTS)：支持事务，如当前存在事务，就沿用，不存在就继续采用无事务方式；
MANDATORY(TransactionDefinition.PROPAGATION_MANDATORY)：必须使用事务，如当前存在事务，就沿用，否则抛出异常；
REQUIRES_NEW(TransactionDefinition.PROPAGATION_REQUIRES_NEW)：新建事务，无论当前事务是否存在，都新建新事务，新事务有自己独立的隔离级别与锁等特性；
NOT_SUPPORTED(TransactionDefinition.PROPAGATION_NOT_SUPPORTED)：不支持事务，当前存在事务时，挂起事务；
NEVER(TransactionDefinition.PROPAGATION_NEVER)：不支持事务，当前存在事务时，抛出异常，否则继续采用无事务方式；
NESTED(TransactionDefinition.PROPAGATION_NESTED)：当前方式调用子方法时，子方法发生异常，只回滚子方法SQL，新事务沿用当前事务的隔离级别和锁等机制；如果数据库支持保存点技术，就启用，否则就等价于REQUIRES_NEW；
@Transactional自调用会失效，是因为AOP的原理是动态代理，自调用是类自身的调用，而不是代理对象去调用，就不会产生AOP，Spring就不能把代码织入约定流程；
解决方法：
（1）用一个Service去调用另一个Service；
（2）从Spring IoC容器中获取代理对象去启用AOP；