轉自 http://www.blogjava.net/killme2008/archive/2007/02/06/98217.html
事務處理是企業應用需要解決的最主要的問題之一。J2EE通過JTA提供了完整的事務管理能力，包括多個事務性資源的管理能力。但是大部分應用都是運行在單一的事務性資源之上（一個數據庫），他們並不需要全局性的事務服務。本地事務服務已然足夠(比如JDBC事務管理）。
本文並不討論應該採用何種事務處理方式，主要目的是討論如何更爲優雅地設計事務服務。僅以JDBC事務處理爲例。涉及到的DAO，Factory,Proxy,Decorator等模式概念，請閱讀相關資料。
也許你聽說過，事務處理應該做在service層，也許你也正這樣做，但是否知道爲什麼這樣做？爲什麼不放在DAO層做事務處理。顯而易見的原因是業務層接口的每一個方法有時候都是一個業務用例（User Case），它需要調用不同的DAO對象來完成一個業務方法。比如簡單地以網上書店購書最後的確定定單爲例，業務方法首先是調用BookDAO對象（一般是通過DAO工廠產生），BookDAO判斷是否還有庫存餘量，取得該書的價格信息等，然後調用CustomerDAO從帳戶扣除相應的費用以及記錄信息，然後是其他服務（通知管理員等）。簡化業務流程大概如此：
首先是業務接口，針對接口，而不是針對類編程：
public interface BookStoreManager{
public boolean buyBook(String bookId,int quantity)throws SystemException; 
.其他業務方法
}
接下來就是業務接口的實現類——業務對象：
public class BookStoreManagerImpl implements BookStoreManager{
public boolean buyBook(String bookId)throws SystemException{ Connection conn=ConnectionManager.getConnection();//獲取數據庫連接 boolean b=false; try{ conn.setAutoCommit(false); //取消自動提交 BookDAO bookDAO=DAOFactory.getBookDAO(); CustomerDAO customerDAO=DAOFactory.getCustomerDAO(); //嘗試從庫存中取書 if(BookDAO.reduceInventory(conn,bookId,quantity)){ BigDecimal price=BookDAO.getPrice(bookId); //取價格 //從客戶帳戶中扣除price*quantity的費用 b= CustomerDAO.reduceAccount(conn,price.multiply(new BigDecimal(quantity)); . 其他業務方法，如通知管理員，生成定單等. conn.commit(); //提交事務 conn.setAutoCommit(true);
} }catch(SQLException e){ conn.rollback(); //出現異常，回滾事務 con.setAutoCommit(true); e.printStackTrace(); throws new SystemException(e); } return b; } }
然後是業務代表工廠：
public final class ManagerFactory { public static BookStoreManager getBookStoreManager() { return new BookStoreManagerImpl(); } }
這樣的設計非常適合於DAO中的簡單活動，我們項目中的一個小系統也是採用這樣的設計方案，但是它不適合於更大規模的應用。首先，你有沒有聞到代碼重複的 bad smell？每次都要設置AutoCommit爲false,然後提交，出現異常回滾，包裝異常拋到上層，寫多了不煩纔怪，那能不能消除呢？其次，業務代表對象現在知道它內部事務管理的所有的細節，這與我們設計業務代表對象的初衷不符。對於業務代表對象來說，瞭解一個與事務有關的業務約束是相當恰當的，但是讓它負責來實現它們就不太恰當了。再次，你是否想過嵌套業務對象的場景？業務代表對象之間的互相調用，層層嵌套，此時你又如何處理呢？你要知道按我們現在的方式，每個業務方法都處於各自獨立的事務上下文當中(Transaction Context），互相調用形成了嵌套事務，此時你又該如何處理？也許辦法就是重新寫一遍，把不同的業務方法集中成一個巨無霸包裝在一個事務上下文中。
我們有更爲優雅的設計來解決這類問題，如果我們把Transaction Context的控制交給一個被業務代表對象、DAO和其他Component所共知的外部對象。當業務代表對象的某個方法需要事務管理時，它提示此外部對象它希望開始一個事務，外部對象獲取一個連接並且開始數據庫事務。也就是將事務控制從service層抽離，當web層調用service層的某個業務代表對象時，返回的是一個經過Transaction Context外部對象包裝（或者說代理）的業務對象。此代理對象將請求發送給原始業務代表對象，但是對其中的業務方法進行事務控制。那麼，我們如何實現此效果呢？答案是JDK1.3引進的動態代理技術。動態代理技術只能代理接口，這也是爲什麼我們需要業務接口BookStoreManager的原因。
首先，我們引入這個Transaction Context外部對象，它的代碼其實很簡單，如果不瞭解動態代理技術的請先閱讀其他資料。
import java.lang.reflect.InvocationHandler;import java.lang.reflect.Method;import java.lang.reflect.Proxy;import java.sql.Connection;import com.strutslet.demo.service.SystemException;public final class TransactionWrapper { /** * 裝飾原始的業務代表對象，返回一個與業務代表對象有相同接口的代理對象 */ public static Object decorate(Object delegate) { return Proxy.newProxyInstance(delegate.getClass().getClassLoader(), delegate.getClass().getInterfaces(), new XAWrapperHandler( delegate)); } //動態代理技術 static final class XAWrapperHandler implements InvocationHandler { private final Object delegate; XAWrapperHandler(Object delegate) { this.delegate = delegate; } //簡單起見，包裝業務代表對象所有的業務方法 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object result = null; Connection con = ConnectionManager.getConnection(); try { //開始一個事務 con.setAutoCommit(false); //調用原始業務對象的業務方法 result = method.invoke(delegate, args); con.commit(); //提交事務 con.setAutoCommit(true); } catch (Throwable t) { //回滾 con.rollback(); con.setAutoCommit(true); throw new SystemException(t); } return result; } }}
正如我們所見，此對象只不過把業務對象需要事務控制的業務方法中的事務控制部分抽取出來而已。請注意，業務代表對象內部調用自身的方法將不會開始新的事務，因爲這些調用不會傳給代理對象。如此，我們去除了代表重複的味道。此時，我們的業務代表對象修改成：
public class BookStoreManagerImpl implements BookStoreManager { public boolean buyBook(String bookId)throws SystemException{ Connection conn=ConnectionManager.getConnection();// 獲取數據庫連接 boolean b=false; try{ BookDAO bookDAO=DAOFactory.getBookDAO(); CustomerDAO customerDAO=DAOFactory.getCustomerDAO(); // 嘗試從庫存中取書 if(BookDAO.reduceInventory(conn,bookId,quantity)){ BigDecimal price=BookDAO.getPrice(bookId); // 取價格 // 從客戶帳戶中扣除price*quantity的費用 b= CustomerDAO.reduceAccount(conn,price.multiply(new BigDecimal(quantity)); . 其他業務方法，如通知管理員，生成定單等. } }catch(SQLException e){ throws new SystemException(e); } return b; } . }
可以看到，此時的業務代表對象專注於實現業務邏輯，它不再關心事務控制細節，把它們全部委託給了外部對象。業務代表工廠也修改一下，讓它返回兩種類型的業務代表對象：
public final class ManagerFactory { //返回一個被包裝的對象，有事務控制能力 public static BookStoreManager getBookStoreManagerTrans() { return (BookStoreManager) TransactionWrapper .decorate(new BookStoreManagerImpl()); } //原始版本 public static BookStoreManager getBookStoreManager() { return new BookStoreManagerImpl(); } }
我們在業務代表工廠上提供了兩種不同的對象生成方法：一個用於創建被包裝的對象，它會爲每次方法調用創建一個新的事務；另外一個用於創建未被包裝的版本，它用於加入到已有的事務(比如其他業務代表對象的業務方法)，解決了嵌套業務代表對象的問題。
我們的設計還不夠優雅，比如我們默認所有的業務代表對象的方法調用都將被包裝在一個Transaction Context。可事實是很多方法也許並不需要與數據庫打交道，如果我們能配置哪些方法需要事務聲明，哪些不需要事務管理就更完美了。解決辦法也很簡單，一個XML配置文件來配置這些，調用時判斷即可。說到這裏，瞭解spring的大概都會意識到這不正是聲明式事務控制嗎？正是如此，事務控制就是AOP的一種服務，spring的聲明式事務管理是通過AOP實現的。AOP的實現方式包括：動態代理技術，字節碼生成技術（如CGLIB庫），java代碼生成（早期EJB採用），修改類裝載器以及源代碼級別的代碼混合織入（aspectj)等。我們這裏就是利用了動態代理技術，只能對接口代理；對類的動態代理可以使用cglib庫。
這篇短文只是介紹下我對事務上下文模式以及聲明式事務管理實現基本原理的理解，如有錯誤，請不吝賜教。我的email:[email protected]