spring 事务管理

最新推荐文章于 2024-11-06 09:59:41 发布

wallacewan

最新推荐文章于 2024-11-06 09:59:41 发布

阅读量650

点赞数

分类专栏：框架及JSP页面设计文章标签： spring bean delete class session nested

框架及JSP页面设计专栏收录该内容

17 篇文章 0 订阅

订阅专栏

声明式的事务管理（Declarative transaction management）：
<1>事务配置方式：

<!-- dataSource for MySQL -->  
<bean id="dataSource"  
        class="org.apache.commons.dbcp.BasicDataSource"  
        destroy-method="close">  
        <property name="driverClassName"  
            value="com.mysql.jdbc.Driver" />  
        <property name="url"  
            value="jdbc:mysql://localhost:3306/springapp" />  
        <property name="username" value="root" />  
        <property name="password" value="root" />  
</bean>

<!-- Hibernate SessionFactory for MySQL -->  
<bean id="sessionFactory"  
    class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">  
        <property name="dataSource" ref="dataSource" />  
        <property name="mappingDirectoryLocations">  
            <list>  
                <value>classpath:/</value>  
            </list>  
        </property>  
        <property name="hibernateProperties">  
            <props>  
                <prop key="hibernate.dialect">  
                    org.hibernate.dialect.MySQLDialect  
                </prop>  
                <prop key="hibernate.show_sql">true</prop>  
                <prop key="hibernate.jdbc.fetch_size">10</prop>  
                <prop key="hibernate.jdbc.batch_size">50</prop>  
            </props>  
        </property>  
</bean>

<!—define transactionManager -->  
<bean id="transactionManager"  
  class="org.springframework.orm.hibernate3.HibernateTransactionManager">  
  <property name="sessionFactory">  
   <ref local="sessionFactory" />  
  </property>  
</bean>

<!—business layer -->  
<bean id="userManageService"  
  class="com.test.service.impl.userManageServiceImpl">  
  <property name="userLoginDao">  
   <ref bean="userLoginDao" />  
  </property>  
…  
</bean>

第一种：使用TransactionProxyFactoryBean，配置声明式事务的方法如下。
(1)表比较少的情况:

<bean id="userManagerServiceProxy"  
  class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">  
  <!-- 配置事务管理器 -->  
  <property name="transactionManager">  
   <ref bean="transactionManager" />  
  </property>  
  <!-- 此属性指定目标类本身是否是代理的对象，如果目标类没有实现任何类，就设为true代表自己 -->  
  <property name="proxyTargetClass">  
   <value>false</value>  
  </property>  
  <property name="proxyInterfaces">  
   <value> com.test.service.userManageService</value>  
  </property>  
  <!-- 目标bean -->  
  <property name="target">  
   <ref bean="userManageService"/>  
  </property>  
  <!-- 配置事务属性 -->  
<property name="transactionAttributes">  
   <props>  
<prop key="delete*">PROPAGATION_REQUIRED</prop>  
<prop key="add*">PROPAGATION_REQUIRED</prop>  
<prop key="update*">PROPAGATION_REQUIRED</prop>  
<prop key="save*">PROPAGATION_REQUIRED</prop>  
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>  
</props>  
</property>  
</bean>

(2)利用继承的思想简化配置,适合相对比较多的模块时使用。

 <bean id="transactionBase"  
  class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"  
  lazy-init="true" abstract="true">  
  <!-- 配置事务管理器 -->  
  <property name="transactionManager">  
   <ref bean="transactionManager" />  
  </property>  
  <!-- 配置事务属性 -->  
  <property name="transactionAttributes">  
   <props>  
<prop key="delete*">PROPAGATION_REQUIRED</prop>  
<prop key="add*">PROPAGATION_REQUIRED</prop>  
<prop key="update*">PROPAGATION_REQUIRED</prop>  
<prop key="save*">PROPAGATION_REQUIRED</prop>  
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>  
</props>  
</property>  
</bean>

而具体的模块可以简单的这样配置。只要指明它的parent（父类）就可以了。父类一般把abstract="true"，因为在容器加载的时候不需要初始化，等到用的时候再有它的子类调用的时候，再去初始化。

<bean id="userManageServiceProxy" parent="transactionBase" >  
  <property name="target">  
  <ref bean="userManageService"/>  
  </property>  
</bean>

第二种：自动创建事务代理的方式。主要利用BeanNameAutoProxyCreator自动创建事务代理

  <!--利用了拦截器的原理。-->  
  <bean id="transactionInterceptor"  
  class="org.springframework.transaction.interceptor.TransactionInterceptor">  
  <property name="transactionManager">   
  <ref bean="transactionManager" />  
  </property>  
  <!-- 配置事务属性 -->  
  <property name="transactionAttributes">  
   <props>  
<prop key="delete*">PROPAGATION_REQUIRED</prop>  
<prop key="add*">PROPAGATION_REQUIRED</prop>  
<prop key="update*">PROPAGATION_REQUIRED</prop>  
<prop key="save*">PROPAGATION_REQUIRED</prop>  
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>  
</props>  
</property>  
</bean>  
<bean id="serviceProxy "  
  class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">  
 <property name="beanNames">  
<list>  
<value>userManageService</value>  
</list>  
<!--或者直接用 <value>*Service</value>-->  
</property>  
  <property name="interceptorNames">  
   <list>  
<value>transactionInterceptor</value>  
</list>  
</property>  
</bean>

<2>事务中异常

<!-- 配置事务属性 -->  
<property name="transactionAttributes">  
   <props>  
<!--指定了 "PROPAGATION_REQUIRED"，表示在当前的事务中执行操作，如果事务不存在就建立一个新的-->  
<prop key="delete*">PROPAGATION_REQUIRED,-ProgramException</prop>  
<prop key="add*">PROPAGATION_REQUIRED,-ProgramException</prop>  
<prop key="update*">PROPAGATION_REQUIRED, -ProgramException</prop>  
<prop key="save*">PROPAGATION_REQUIRED, -ProgramException</prop>  
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>  
</props>  
</property>

Spring中对异常的回滚，默认是在抛出运行时异常(RuntimeException)时才回滚，对非运行时异常不回滚。如果使用-Exception,意思是对所有的异常异常都回滚。Exception前面加上 "-" 时，表示发生指定异常时撤消操作(rollback)，如果前面加上 "+"，表示发生异常时立即提交（commit）。
要想用Spring的事务管理机制，就需要把数据库的连接交给Spring来管理，（JDBC,SESSION道理一样），如果使用Hibernate框架，要把Session交给Spring管理。在整个Service方法调用中，虽然Sevice调用了多个Dao，但是整个过程中Session只有一个。也就是说你对数据库的DML操作，都会先保存在这个Session中，包括update,insert,delete。当发生异常（这个异常可以是数据库的，也可以是程序的），Spring会把这个Session中对应的DML操作回滚。
<3>事务的属性
(1) 传播行为

PROPAGATION_MANDATORY: 方法必须在一个现存的事务中进行，否则丢出异常
PROPAGATION_NESTED: 在一个嵌入的事务中进行，如果不是，则同PROPAGATION_REQUIRED
PROPAGATION_NEVER: 指出不应在事务中进行，如果有就丢出异常
PROPAGATION_NOT_SUPPORTED: 指出不应在事务中进行，如果有就暂停现存的事务
PROPAGATION_REQUIRED: 在当前的事务中进行，如果没有就建立一个新的事务
PROPAGATION_REQUIRES_NEW: 建立一个新的事务，如果现存一个事务就暂停它
PROPAGATION_SUPPORTS: 支持现在的事务，如果没有就以非事务的方式执行

(2) 隔离层级

ISOLATION_DEFAULT: 使用底层数据库预设的隔离层级
ISOLATION_READ_COMMITTED: 允许事务读取其他并行的事务已经送出（Commit）的数据字段，可以防止Dirty read问题
ISOLATION_READ_UNCOMMITTED: 允许事务读取其他并行的事务还没送出的数据，会发生Dirty、Nonrepeatable、Phantom read等问题
ISOLATION_REPEATABLE_READ: 要求多次读取的数据必须相同，除非事务本身更新数据，可防止Dirty、Nonrepeatable read问题
ISOLATION_SERIALIZABLE: 完整的隔离层级，可防止Dirty、Nonrepeatable、Phantom read等问题，会锁定对应的数据表格，因而有效率问题

(3) 只读提示（Read-only hints）
如果事务只进行读取的动作，则可以利用底层数据库在只读操作时发生的一些最佳化动作，由于这个动作利用到数据库在只读的事务操作最佳化，因而必须在事务中才有效，也就是说要搭配传播行为PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED来设置。
(4)事务超时期间（The transaction timeout period）
有的事务操作可能延续很长一段的时间，事务本身可能关联到数据表的锁定，因而长时间的事务操作会有效率上的问题，对于过长的事务操作，考虑Roll back事务并要求重新操作，而不是无限时的等待事务完成。
可以设置事务超时期间，计时是从事务开始时，所以这个设置必须搭配传播行为PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、PROPAGATION_NESTED来设置。
事务的超时属性以timeout_为前缀和一个整型数字定义，

例如： <prop key="query*">PROPAGATION_REGUIRED,timeout_5,readOnly</prop>

关于PROPAGATION_NESTED

使用嵌套事务的场景有两点需求：

需要事务BC与事务AD一起commit，即：作为事务AD的子事务，事务BC只有在事务AD成功commit时（阶段3成功）才commit。这个需求简单称之为“联合成功”。这一点PROPAGATION_REQUIRED可以做到。
需要事务BC的rollback不（无条件的）影响事务AD的commit。这个需求简单称之为“隔离失败”。这一点PROPAGATION_REQUIRES_NEW可以做到。

使用PROPAGATION_REQUIRED满足需求1，但子事务BC的rollback会无条件地使父事务AD也rollback，不能满足需求2。

使用PROPAGATION_REQUIRES_NEW满足需求2，但子事务（这时不应该称之为子事务）BC是完全新的事务上下文，父事务（这时也不应该称之为父事务）AD的成功与否完全不影响BC的提交，不能满足需求1。

同时满足上述两条需求就要用到PROPAGATION_NESTED了。

PROPAGATION_NESTED在事务AD执行到B点时，设置了savePoint（关键）。

当BC事务成功commit时，PROPAGATION_NESTED的行为与PROPAGATION_REQUIRED一样。只有当事务AD在D点成功commit时，事务BC才真正commit，如果事务AD rollback，事务BC也将一起rollback ，从而满足了“联合成功”。

当BC事务rollback时，因为设置了savePoint，AD事务可以选择与BC一起rollback或继续执行并保留之前的执行结果，从而满足了“隔离失败”。

当然，要明确一点，事务传播策略的定义是在声明或事务管理范围内的（首先是在EJB CMT规范中定义，Spring事务框架补充了PROPAGATION_NESTED），编程式的事务管理不存在事务传播的问题。

另外，SavePoint在JDBC3.0中，所以应用嵌套事务必须保证JDK1.4+和驱动对JDBC3.0的支持

强调，补充一点：PROPAGATION_NESTED只是Spring针对JDBC3.0以上版本SavePoint机制的一个事务传播机制的扩展，J2EE体系中是没有的，所以如果应用中使用JTA作为底层的事务管理机制的话，使用Spring也是不可能支持PROPAGATION_NESTED。不过JPA的体系中好像是有SavePoint的机制（还没有细研究过），Spring应该可以在之上做相应的支持。这点有待进一步研究！