1.spring实现对事务的控制，使用的是代理的技术。通过生成的代理类来捕捉被代理类（也就是我们编写的类）的异常，决定事务的提交或回滚。从某一角度来说，spring事务是基于异常实现的。对于实现了接口的类，spring默认使用jdk动态代理进行处理，典型例子是系统的service层服务，一般都需要实现接口。对于没有实现接口的类，如web项目中的Controller，spring使用cglib进行代理。
2.最好不要在需要事务控制的方法中，调用本类的其他方法。由于该类需要spring进行事务控制，因此会生成代理类。如果是基于jdk动态代理生成的代理类，那么在被代理类中方法A用this调用该类的B方法，实际上调用的不是代理类的代理过的B方法，还是被代理类的原生B方法，这样的话，B方法上的事务不会起作用；如果使用cglib进行代理，因为cglib基于继承进行代理，this不会出现上述问题，但理论上调用私有方法时，子类对象是访问不到父类私有方法的。
总之，如果需要spring进行事务控制，那么不要在一个方法中调用同一个类中的另一个方法。
3.默认情况下，spring遇到RuntimeException才会回滚，即unchecked异常。
4.spring一共定义了七种事务传播机制：
PROPAGATION_REQUIRED – 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS – 支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY – 支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW – 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED – 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER – 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED – 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。
其中，常用的是：
PROPAGATION_REQUIRED，这个也是默认的传播机制；
PROPAGATION_NOT_SUPPORTED，可以用于发送提示消息，站内信、短信、邮件提示等。不属于并且不应当影响主体业务逻辑，即使发送失败也不应该对主体业务逻辑回滚。
PROPAGATION_REQUIRES_NEW，总是新启一个事务，这个传播机制适用于不受父方法事务影响的操作，比如某些业务场景下需要记录业务日志，用于异步反查，那么不管主体业务逻辑是否完成，日志都需要记录下来，不能因为主体业务逻辑报错而丢失日志；
PROPAGATION_NESTED，基于数据库savepoint实现的嵌套事务，父方法事务的commit和rollback能够控制嵌套子事务，而嵌套子事务报错时，可以选择rollback，返回原始savepoint，父事务继续执行。该传播机制可以解决发生在REQUIRED传播机制下rollback_only的问题（rollback_only的具体场景可以google一下）。