关于把webservice加在事务内的一些影响分析

本文作者：

蔡述尧

问题场景描述（即问题出现的具体现象）：

把webservice加在事务内的一些影响分析

适用环境（例如此经验仅限于某些版本，或者仅限于特定的操作系统、数据库、J2EE应用服务器环境）：

通用

解决经验（包括原因分析、解决方法或过程等）：

1、把webservice加在事务中不能解决事务一致性的问题

由于webservice的调用不能传递事务，因此webservice并不能解决事务的一致性。如下所示：

begin --A --B(ws)--C --End(commit) 在事务中嵌入B操作为webservice ，

如果在C操作处发生异常，事务回滚。对B操作对应的webservice中的动作是不会被回滚的。

如果在B操作的远程系统中出现了异常，远程系统中截获并做了回滚后，对应当前的系统，此次调用是成功的不会有任何异常导致当前事务回滚，除非B操作返回值有标识，并且本地做了判断进行回滚。

如果在A处发生异常，则无论B是否在事务内都不重要了。

对于都成功或者都失败的情况，B是否在事务内并不重要。

可见只有在B操作出现网络异常或者WebService调用的API内部异常，时才会对事务一致有些帮助。

事实上，建议使用业务补偿，与异常状态列表监控（把未成功的业务记录下来，自动或者手动处理）

2、把webservice加在事务中不能解决导致的问题

webservice是一个较慢的操作，由于通过远程访问系统，同时xml的解析也是相对较慢的操作。将webservice加入的事务内，会导致事务的 时间变长，而事务中通常会锁定一些业务数据。这些业务数据的锁定时间增长后，会导致系统中对业务数据表的记录锁定，特别是在并发高峰期，容易产生 恶性循环，影响系统的响应与负载能力。

webservice由于没有接收到本地事务的传递，webservice所对应的远程操作是一个独立的事务，一旦webservice的对应操作需要对流程数据进行一些变更（这个是很有可能的，如状态改变，流程相关数据中变量值修改等），如果远程与本地操作的都是同一个流程，会导致流程实例记录在数据库端发生死锁。

从以上来看首先把webservice加入到事务中不能根本的解决事务一致性问题，反而容易引发资源竞争导致系统响应变慢。得不偿失，建议把 webservice从事务中移除，使用业务补偿，业务判断，异常列表等手段解决。

注意事项（需要指出的注意点）：

无