Transaction Design Pattern

有三种方式处理事务的模式

 

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