WebLogic Server中CMP實體bean的性能調優[2]

　　數據庫并發策略是目前WebLogic Server版本中的默認并發策略。它提供了數據持久性和性能間的折中考慮。原理很簡單：WebLogic Server并不自己管理鎖，而是為每個試圖訪問該bean的每個事務創建一個新的bean實例，并將并發控制和死鎖檢測委派給底層數據庫。這就像多個客戶端對單個數據庫進行并行數據庫操作；數據庫的隔離水平和鎖定策略將規定哪些更新、選擇和插入會進行，按照何種順序，以及哪些（如果有的話）會失敗。直接好處是該策略在集群環境中的良好適用性——只要集群中的所有節點共享一個數據庫，EJB容器就不需要為數據同步細節而煩惱。

　　該策略明顯比排他性策略更具伸縮性，并且對于某些應用程序效果尤為出眾，但是也無法擺脫一些嚴重的性能限制。即使這樣，容器仍保持了一個實體bean實例池，并且這些實例不包含事務間的任何中間狀態。這是實例池化而不是緩存數據。池化無狀態實例的整體思想可能來自于早期的JVM實現，那時對象創建還是一項很昂貴的操作，并且從性能的角度來看緩存對象實例是有好處的。在現代的JVM中情況并非如此，因為大部分情況下對象的創建非?？?，但是由于該行為是EJB規范中描述的，所有供應商都應支持它。然而，當使用數據庫并發策略時，容器從緩存中取出“無狀態的”bean實例，并且必須執行一條SQL選擇操作以獲得最新數據并填充實例字段。

　　這種方法可能還不錯，因為我們不用擔心“不新鮮的”bean實例（當數據庫中的數據被從同一集群中的另一個節點或者從不同應用程序中更新時），但是性能也同樣受到明顯影響。您總是在每次事務的開始以一個額外的select操作結束，即使您只是打算更新bean中的數據而對之前的值并不感興趣。因此，在主要或僅是執行更新或插入操作的應用程序中使用實體bean意義不大——容器可能花大量時間做不必要的選擇操作，然后再拋棄數據。

　　排他性和數據庫并發策略至少存在一個共同問題：更新丟失的可能性?？梢韵胂髢蓚€客戶端幾乎同時更新映射到一個實體bean的表中的同一條記錄。如果數據庫中沒有鎖，先完成的更新操作的結果會被其次完成的更新所覆蓋。這是否是可接受的結果取決于您的業務需求。更新丟失通常是不可接受或者不想要的；因此，應用程序需要某種機制來避免或檢測更新丟失的情況，并且有機會恢復。當應用程序部署再多個節點上時使用排他性策略將不能控制更新丟失問題。但是如我之前所述，您不應再考慮該該策略。

　　數據庫策略通過將并發控制委派給數據庫，提供了進行讀數據操作時在數據庫中使用排他性鎖的選擇。這是通過將weblogic-cmp-jar.xml中的use-select-for-update元素設置為true（默認為false）來實現的。顧名思義，該動作告訴WebLogic Server在加載實體bean數據時使用“select for update”。生成的數據庫鎖一致存在，直到事務完成，因此其他事務不可能在第一個事務運行期間讀取或更改數據。該項技術也許在“select for update”上組合了“no wait”選項，可能解決更新丟失問題以及任何可能的死鎖——只不過代價很高。

　　該方法的一個缺點是性能會降低，因為一旦一個事務鎖住一個實體實例，其他事務就不能訪問同樣的實體數據，即使它們需要的是只讀訪問。這基本上就是另一種排他性策略，唯一的區別是這次它可用于集群環境，因為所有的鎖定都發生在（共享）數據庫中而不是服務器實例上。第二個缺點是bean的行為在某種程度上依賴于底層數據庫的鎖策略實現。比如，有些數據庫支持細粒度、行級的鎖定，而有些則不然。在后一種情況中，對整個記錄頁的訪問可能被作為單個實體加載操作的結果而被阻止。

原文轉自：http://www.anti-gravitydesign.com