隨筆檔案(496)

?????? 在現在的B/S體系結構的軟件開發中，對于數據庫事務處理中最常使用的方式是每個用戶請求一個事務。也就是說，當服務器端接收到一個用戶請求后，會開始一個新的事務，直到對用戶請求的所有處理都進行完畢并且完成了響應用戶請求的所有輸出之后才會關閉這個事務。

?????? 對于使用Hibernate實現持久化功能的系統來說，事務的處理是這樣的：服務器端在接收到用戶的請求后，會創建一個新的Hibernate Session對象，然后通過該Session對象開始一個新的事務并且之后所有對數據庫的操作都通過該Session對象來進行。最后，完成將響應頁面發送到客戶端的工作后再提交事務并且關閉Session。

?????? Session的對象是輕型的，非線程安全的，所以在每次用戶請求時創建，請求處理完畢后丟棄。

?????? 那么，該如何實現這種方式的事務處理呢？處理的難點在于如何在業務處理之前創建Session并開始事務以及在業務處理之后提交事務并關閉Session。對于現在的Web應用來說，通常情況下是通過ServletFilter來完成事務處理的操作。這樣，就可以輕松地實現在用戶請求到達服務器端的時候創建Session并開始事務，而服務器端響應處理結束之前提交事務并關閉Session。

?????? 另外一個問題是，在ServletFilter中創建的Session是如何傳遞給業務處理方法中的呢？處理的方法是通過一個ThreadLocal變量來把創建的Session對象綁定到處理用戶請求的線程上去，這樣就可以使任何的業務處理方法可以輕松得到Session對象。

?????? Hibernate中事務處理的具體方法可以參照前面的網絡博客的實例。

?????? 但是這種事務處理的方式還是會遇到一些問題，其中最突出的就是更新沖突的問題。例如，某個操作人員進入了用戶信息的修改頁面，在經過一段時間的對用戶信息的修改后，進行提交操作，而與此同時可能會有另外一個操作人員也進行了相同的操作，這樣在處理提交的時候就會產生沖突。

?????? 產生這個沖突的原因在于在開發中需要使用多個數據庫事務來實現一個應用事務。也就是說，在應用程序層，應該將讀取用戶信息、顯示修改頁面以及用戶提交工作來作為一個事務進行處理，在處理的過程中應該避免其他操作人員進行類似的操作。

?????? 回想前面的介紹，我們對于數據庫事務所采取的策略是每個用戶請求一個事務，而上面的業務處理則至少需要兩個請求才能完成。這樣，兩者之間就存在著一定的矛盾，這也就導致了不可重復讀取和兩次更新問題的發生。

?????? 為了解決并發中數據訪問的問題，通常會采用鎖的機制來實現數據訪問的排他性，從而避免兩次更新問題的發生。