关与shark的数据库死锁

      这几天项目遇到了点问题,就是在shark多个用户同时点完成是出现死锁,  环境就是我前几篇文章说的那样,一开始我查了一下代码,我用的是spring的事务管理方法(另我用的是jotm事务) 引用一个别人的文章,写的不错(http://jie2workjava.javaeye.com/blog/446250),发现如果用spring来管理事务的话,一个事务最小的长度也只能是一个方法,而且不能在入口方法的被调用方法加事务,就是method1()中调用method2(),而如果你在method2方法中定义的事务,而如果你在外部调用method1方法的话是不会开启事务的(原因可以想一下gof的代理模试的实现),而shark要求每次访问都要开启一个事务,所以没办法我只好重构了一下我的sharkAdapter类,把所有的shark的方法都放到sharkAPIAdapter类中(原来只有一部分),并对每个shark调用的方法定义事务,来缩短事务的长度,然后在查看我的service层中把不必要的事务全部去掉,这样即使service层的类不开启事务调用我封装的shark功能时(如workMgr,processMgr等)也能开启一个供shark使用的事务(shark要求调用API时必须开启事务),当然在service层来有必须保留的事务处理,像这样要保留的事务处理方法,我也进行了重构让不必在事务中的查询操作在事务之外,由于spring有定义的事务隔离方式,所在不用担心嵌套事务,关于这点看这(http://fhjxp.javaeye.com/blog/124978)总之就是说method1()调用method2()而两个方法都定义了事务,而你的事务隔离级别为"PROPAGATION_REQUIRED"那么在调用method1时只开启一次事务,而不是嵌套事务.经过上述改动,shark数据库死锁已经好了一些了.但是发生的机率还是不可被接受,在同时调用一个方法时还是会出现死锁,我感觉这和shark的内部机制有关系(另外可能也和我用的数据库有关,我用的是MSSQL,因为MSSQL的死锁机制和Oracle的不同,我想如果我使用Oracle的话可能会好一些),因为我已经将事务缩到最短了,短到只调用一个sharkAPI的complete方法.这另我很挠头,于是在网上查了一下发现shark有个收费插件,就可以最小化死锁:Shark Extended Transaction ETB  (http://www.together.at/together/prod/shkaddon/shket/index.html)可是这东东是4000多美刀,有总被骗的感觉,于是再想别的办法,由于是多线层并发调用时出现的死锁也就是说是同时调用的shark的api这样的说我用线程互斥锁来限制一下,在可能会产生死锁的sharkAPI方法的Adapter中加入synchronized关键字,再调整了一下事务的timeout(不知道这个有没有作用),这样死锁的产生终于可以被接受了.