因为最近时间在解决公司工作流在客户现场的高并发情况下经常出现死锁（dead lock）或者事务超时情况，而工作流的应用大多数主要这几种业务：查询工作项、领取工作、完成（或者提交）工作。根据以前公司在其他应用中并没有出现这 些故障，对所上线的环境进行的分析，主要差异是出问题的系统是DB2（其他系统基本上是ORACLE）。针对上面的问题进行了下面分析。

 

数据库的差异性：

数据库的隔离级别分析：

JDBC的数据隔离级别设置：

 

JDBC	数据库隔离级别	数据访问情况
TRANSACTION_READ_UNCOMMITTED	ur	就是俗称“脏读”（ dirty read），在没有提交数据时能够读到已经更新的数据
TRANSACTION_READ_COMMITTED	cs	在一个事务中进行查询时，允许读取提交前的数据，数据提交后，当前查询就可以读取到数据。update数据时候并不锁住表
TRANSACTION_REPEATABLE_READ	rs	在一个事务中进行查询时，不允许读取其他事务update的数据，允许读取到其他事务提交的新增数据
TRANSACTION_SERIALIZABLE	rr	在一个事务中进行查询时，不允许任何对这个查询表的数据修改。

 

在websphere环境中通过JDBC连接DB2数据库的隔离级别的情况：

工作流应用分析：

 

    在工作流应用中，主要是这些操作：查询工作项、领取工作、完成（或者提交）工作。

    根据上面的应用分析，工作流应用中大量的select，少量对数据进行update，而发生死锁（dead lock）的现象是在DB2，在ORACLE上基本没有发生的主要原因是：

 

    在DB2中数据库的隔离级别是rs，如果系统中有大量的select，特别是如果查询的工作项特别多，查询慢的情况下，造成其他的update操作等待select请求结束，如果又有大量的select请求过来时会出现死锁（dead lock）

 

解决方案：

 

    首先考虑参照ORACLE的模式，将DB2的JDBC连接的隔离级别改为TRANSACTION_READ_COMMITTED，来提高并发能力，通常情况下获取数据库连接都是通过一个方法获得，因此可以直接改这个方法获得连接后直接将JDBC的Connection的隔离级别调整为TRANSACTION_READ_COMMITTED。但是在验证这种方案是发现了一个问题：

    如果在一个JTA事务中，先获取一个JDBC的Connection，程序修改了隔离级别到TRANSACTION_READ_COMMITTED， 在这个Connection中进行了数据库操作，然后关闭连接，再从数据源中获取Connection时候，DB2的Driver会修改当前的连接的隔离 级别，造成了在一个全局事务中修改了隔离级别，系统会自动抛出异常。

 

    上面的方案中是对任何一个Connection都修改隔离级别，因为存在问题，因此只能对单个数 据库请求进行隔离级别的操作。对所有的获取工作项的select查询语句之后添加上 with cs的方式，这样这条查询请求并不会锁住表，其他update操作就能够正常工作。