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