有三种方式处理事务的模式
1. Client Own Transaction
应用场景:
服务端Service 组件不允许修改,且都是细粒度的服务,一次调用不能满足一个ACID的业务请求
由于客户端transaction context需要传播propagation到Server端,需要RMI协议支持。好像Spring中不支持。
通过RMI,EJB这种方式的话要求客户端用programmatic 事务处理,服务端需要用declarative 事务处理。这是因为transaction context不能在programmatic事务处理中传播。
缺点:
多次远程服务调用影响性能
方式:
统一由客户端发起,提交,rollback事务。
Server端组件事务读操作声明成support, 其他写操作需声明成Mandatory
2. Domain Service Own Transaction
应用场景:
服务端提供了粗粒度的服务封装
客户端不能管理事务,如Web Service Client(服务端封装成了Web Service)
减轻客户端的复杂度
方式:
事务只在这一层处理发起,提交,rollback
Server端组件事务读操作声明成support, 其他写操作需声明成Required
3. Service Delegate Own Transaction
以上1和2的折中,相当于在Client和Server之间加入了一个Business Delegate层。
事务统一在这一层处理。
好处:
后端的Server层可以剥离Transaction相关的API,用POJO写
缺点:
客户端的逻辑(如一次请求多个服务端的调用)需要移到这一层,可能依赖于UI层的框架API,如HttpServletRequest之类的
方式:
该层方法事务读操作声明成support, 其他写操作需声明成Required