【转载】JBPM之长事务设计解析

JBPM之长事务设计解析

 

 

 

       在企业开发中，很多时候我们需要把一些业务数据持久化到数据库中；在数据要求不是很高的场景下，我们可以不用考虑事务的提交和回滚；但是很多时候，我们面临的很多的数据库脚本需要保证要成功就都执行成功，否则就要回滚；特别是在流程运行中提交时，我们需要处理上一个节点的相关数据，同时也要处理提交到得节点的相关数据，我们需要保证这些数据的正确性和一致性，特别是在发生异常时，我们需要回滚所有的操作。今天我们来分析一下JBPM的事务设计。

 

       JBPM数据库长事务处理是通过拦截器和具体的承载数据库脚本的命令完成的，下面分别进行简单的分析(以下分析是针对hibernate事务进行分析，sping和jta事务的原理都是一样的)

 

拦截器Interceptor

 

 

SkipInterceptor:在相应的资源已经初始化后，则直接跳过后边的拦截器直接执行命令脚本；

 

RetryInterceptor:防止hibernate的乐观并发策略导致命令执行中断，按照设置的时间间隔和

 

重试最大次数进行重试执行。

 

EnvironmentInterceptor:根据设置重新构建环境资源或者直接获取已经最在的当前环境资源；

 

StandardTransactionInterceptor:负责事务的管理;

 

DefaultCommandService:最终负责调用具体的数据库脚本命令；

 

脚本命令Command

 

脚本命令封装完成某个业务功能需要的数据库脚本。

 

运行机制

 

配置拦截器使用策略

 

       我们可以在jbpm.tx.hibernate.cfg.xml配置文件中进行设置

 

       <command-service name="txRequiredCommandService">

 

      <skip-interceptor />

 

      <retry-interceptor />

 

      <environment-interceptor />

 

      <standard-transaction-interceptor />

 

    </command-service>

 

 

 

    <command-service name="newTxRequiredCommandService">

 

      <retry-interceptor />

 

      <environment-interceptor policy="requiresNew" />

 

      <standard-transaction-interceptor />

 

</command-service>

 

 

 

解析拦截器配置策略

 

    由CommandServiceBinding解析配置文件中的command-service元素，并生成

 

对应的CommandServiceDescriptor进行缓存；

 

初始化拦截器

 

       当我们首次使用或者获取流程引擎中的TaskService等任何一个服务，就会根据拦

 

截器配置策略进行初始化拦截器；但是初始化后会进行全局缓存，以后不会每次进行

 

新建初始化；

 

具体命令执行

 转自：http://www.cnblogs.com/wufengtinghai/archive/2011/06/25/2090312.html