在通过JDBC对数据库进行并发访问时，为了解决并发之间的锁的控制，JDBC提供了一个隔离级别（Isolation）的方式解决并发访问的问题。
因为最近时间在解决公司工作流在客户现场的高并发情况下经常出现死锁（dead lock）或者事务超时情况，而工作流的应用大多数主要这几种业务：查询工作项、领取工作、完成（或者提交）工作。根据以前公司在其他应用中并没有出现这 些故障，对所上线的环境进行的分析，主要差异是出问题的系统是DB2（其他系统基本上是ORACLE）。针对上面的问题进行了下面分析。
数据库的差异性：
- ORACLE数据库比较强调能够支持高并发情况下的访问，保证能够“读”到数据
- DB2数据库比较强调高并发情况下的数据完整性，保证能够“读一致”的数据
数据库的隔离级别分析：
- ORACLE缺省使用的是CS级别的数据库访问
- DB2缺省使用的是RS级别的数据库访问
JDBC的数据隔离级别设置：
|
JDBC
|
数据库隔离级别
|
数据访问情况
|
|
TRANSACTION_READ_UNCOMMITTED
|
ur
|
就是俗称“脏读”（dirty read），在没有提交数据时能够读到已经更新的数据
|
|
TRANSACTION_READ_COMMITTED
|
cs
|
在一个事务中进行查询时，允许读取提交前的数据，数据提交后，当前查询就可以读取到数据。update数据时候并不锁住表
|
|
TRANSACTION_REPEATABLE_READ
|
rs
|
在一个事务中进行查询时，不允许读取其他事务update的数据，允许读取到其他事务提交的新增数据
|
|
TRANSACTION_SERIALIZABLE
|
rr
|
在一个事务中进行查询时，不允许任何对这个查询表的数据修改。
|
在websphere环境中通过JDBC连接DB2数据库的隔离级别的情况：
- 只有使用实体（Entity Bean）的情况下可以通过修改ibm的部署文件修改当前数据操作的隔离级别
- 如果通过session bean，jdbc connection方式获得的数据库连接缺省都是TRANSACTION_REPEATABLE_READ
- 在通过数据源获得DB2的数据库连接时候，DB2的JDBC driver会缺省修改当前连接的隔离级别到TRANSACTION_REPEATABLE_READ
工作流应用分析：
在工作流应用中，主要是这些操作：查询工作项、领取工作、完成（或者提交）工作。
- 查询工作项，数据库操作是select，在工作流应用中的操作频率最高
- 领取工作，数据库操作是update，在工作流应用中的操作频率较低
- 完成（或者提交）工作，数据库操作主要是update、insert，在工作流应用中的操作频率较低
根据上面的应用分析，工作流应用中大量的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操作就能够正常工作。