四十一、在Spring框架中如何更有效地使用JDBC?
参考回答：
使用SpringJDBC 框架，资源管理和错误处理的代价都会被减轻。所以开发者只需写statements 和 queries从数据存取数据，JDBC也可以在Spring框架提供的模板类的帮助下更有效地被使用，这个模板叫JdbcTemplate （例子见这里here）
四十二、Spring支持的事务管理类型？
参考回答：
Spring支持两种类型的事务管理：
（1）编程式事务管理：这意味你通过编程的方式管理事务，给你带来极大的灵活性，但是难维护。
（2）声明式事务管理：这意味着你可以将业务代码和事务管理分离，你只需用注解和XML配置来管理事务。
四十三、Spring框架的事务管理有哪些优点？
参考回答：
（1）它为不同的事务API 如 JTA，JDBC，Hibernate，JPA 和JDO，提供一个不变的编程模式。
（2）它为编程式事务管理提供了一套简单的API而不是一些复杂的事务API。
（3）它支持声明式事务管理。
（4）它和Spring各种数据访问抽象层很好的集成。
四十四、你更倾向用那种事务管理类型？
参考回答：
大多数Spring框架的用户选择声明式事务管理，因为它对应用代码的影响最小，因此更符合一个无侵入的轻量级容器的思想。声明式事务管理要优于编程式事务管理，虽然比编程式事务管理（这种方式允许你通过代码控制事务）少了一点灵活性。
四十五、Spring事务的配置有几种不同的方式
参考回答：
（1）每个Bean都有一个代理
（2）所有Bean共享一个代理基类
（3）使用拦截器
（4）使用tx标签配置的拦截器
（5）全注解
四十六、事务注解在类/方法上的优先级以及你对事务注解使用的一些建议。
参考回答：
如果在接口、实现类或方法上都指定了@Transactional 注解，则优先级顺序为：
方法>实现类>接口；
建议只在实现类或实现类的方法上使用@Transactional，而不要在接口上使用，这是因为如果使用JDK代理机制（基于接口的代理）是没问题；
而使用使用CGLIB代理（继承）机制时就会遇到问题，因为其使用基于类的代理而不是接口，这是因为接口上的@Transactional注解是“不能继承的”；
四十七、事务的回滚规则
参考回答：
默认只把RuntimeException及其子类标记为回滚，Error默认也导致回滚。Checked Exceptions默认不导致回滚。这些规则和EJB是一样的。
四十八、为何有时@Transactional不生效
参考回答：
只有@Transactional 注解应用到 public 方法，才能进行事务管理。
这是因为在使用 Spring AOP 代理时，Spring 在调用 TransactionInterceptor 在目标方法执行前后进行拦截之前，DynamicAdvisedInterceptor（CglibAopProxy 的内部类）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法会间接调用 AbstractFallbackTransactionAttributeSource（Spring 通过这个类获取@Transactional 注解的事务属性配置属性信息）的 computeTransactionAttribute 方法。如果想在非public方法上生效，考虑使用AspectJ（织入方式）。
注意：即使你的方法是public的，但是如果被private的方法调用，@Transactional注解同样也会失效
四十九、Spring事务三要素
参考回答：
数据源：表示具体的事务性资源，是事务的真正处理者，如MySQL等。
事务管理器：像一个大管家，从整体上管理事务的处理过程，如打开、提交、回滚等。
事务应用和属性配置：像一个标识符，表明哪些方法要参与事务，如何参与事务，以及一些相关属性如隔离级别、超时时间等。
五十、逻辑事务与物理事务
参考回答：
事务性资源实际打开的事务就是物理事务，如数据库的Connection打开的事务。Spring会为每个@Transactional方法创建一个事务范围，可以理解为是逻辑事务。
在逻辑事务中，大范围的事务称为外围事务，小范围的事务称为内部事务，外围事务可以包含内部事务，但在逻辑上是互相独立的。每一个这样的逻辑事务范围，都能够单独地决定rollback-only状态。
那么如何处理逻辑事务和物理事务之间的关联关系呢，这就是传播特性解决的问题。
