8.Spring的事务管理难点剖析

1.DAO和事务管理的牵绊：

  1.1 脱离了事务性，DAO照样可以顺利的进行；对于强调读速度的应用，数据库本事可能就不支持事务：如MyISAM引擎的MySQL数据可。这时，即使在应用中配置事务管理器，也没实际用。

  1.2 Hibernate访问数据库：

        Hibernate的事务管理拥有其自身的意义，它和Hibernate一级缓存存在密切的关系：当我们调用Session的save、update等方法时，Hibernate并不直接向数据库发送SQL语句，只在提交事务（commit）或flush一级缓存时才向数据库发送SQL。所以，即使底层数据库不支持事务，Hibernate的事务管理也不会对数据操作的效率造成负面影响。所以，如果使用Hibernate数据访问技术，没理由不配置HibernateTransactionManager事务管理器。（当然，不使用Hibernate 事务管理器，在Spring中，Hibernate也可以工作）。

  1.3 应用分层的迷惑：Web，Service、Dao三层划分不是必须的。Spring框架所提供的各种好处（如AOP、注解增强、注解MVC等）的唯一前提就是让POJO的类变成一个受Spring容器管理的Bean，除此之外没有任何要求。比如：用一个POJO完成所有的功能，既是Controller，又是Service，还是Dao。（书P331）

  1.4 多线程的困惑：正常配置下，在相同线程中进行相互嵌套调用的事务方法工作于相同的事务中。如果这些相互嵌套调用的方法工作在不同的线程中，则不同线程下的事务方法工作在独立的事务中。

  1.5 联合军种作战的混乱

        很多应用中，往往采用多个数据访问技术：一般是两种，一种采用ORM技术框架，另一种采用偏JDBC的底层技术。如果你采用了一个高端ORM技术（Hibernate、JPA、JDO），同时采用一个JDBC技术（Spring JDBC、iBatis），由于前者的会话（Session）是对后者连接（Connection）的封装，Spring会“足够智能地”在同一个事务线程让前者的会话封装后者的连接。所以，我们只要直接采用前者的事务管理器就可以了。

                 混合数据访问技术框架所对应的事务管理器：

混合数据访问技术框架	事务管理器
Hibernate+ Spring JDBC或iBatis	org.springframework.orm.hibernate3.HibernateTransactionManager
JPA+Spring JDBC或iBatis	org.springframework.orm.jpa.JpaTransactionManager
JDO+Spring JDBC或iBatis	org.springframework.orm.jdo.JdoTransactionManager

eg. Hibernate+Spring JDBC混合框架的事务管理 实例（书P341）

      注：合适的时候需要显示调用 Hibernat里的flush()方法，将Session中的缓存同步到数据库中。原因：在默认情况下， Hibernate对数据的更改只是记录在一级缓存中，要等事务提交或显示调用flush()方法时才将一级缓存中的数据同步到数据库中。

1.6 特殊方法成漏网之鱼

动态代理策略	不能被事务增强 的方法
基于接口的动态代理	除public外的其他所以方法，此外public static也不能被增强
基于CGLib的动态代理	privat、static、final的方法

注意，这些方法不能被Spring进行AOP事务增强，是指这些方法不能启动事务，但是外层的事务上下文依旧可以顺利地传播到这些方法中。 这些不能被Spring事务增强的方法和可被Spring事务增强的方法 唯一的区别在于“是否可以主动启动一个新事务”：前者不能后者可以。对于事务传播行为来说，二者是完全相同的。

1.7数据连接泄漏

    如果代码中直接获取Connection，如不及时关闭，可能会造成连接泄漏。实例：书P351

    如何获取这些被Spring管控的数据连接呢？ Spring提供了两种解决方法：其一是使用数据资源获取工具类；其二是对数据源（或其衍生品如Hibernate SessionFactory）进行代理。

    通过DataSourceUtils获取数据连接，如果不掉用release方法释放连接，只能防止事务方法里的数据连接泄漏，如果还想在一般方法里防止这个问题，必须显示调用release方法（注：放在finally后面）。见书P356.

   代码获取数据源，对数据源（或其衍生品如Hibernate SessionFactory）进行代理只是能处理存在事务上下文的方法里的连接泄漏问题。

   不同数据访问框架DataSourceUtils与TransactionAwareDataSourceProxy的等价类（书P359）

   总结，如果要直接获取Connection，不及时关闭，就很可能造成连接泄漏。为降低连接泄漏的可能性，尽量使用DataSourceUtils获取数据连接，别忘了调用在finally里显示调用这个DataSourceUtils的releaseConnection释放连接