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

　　WebLogic Server中CMP實體bean的性能調優[10]  軟件測試

　　Read-mostly數據

　　也許最常見的情形是，數據被讀取的頻率大于其被更改的頻率。這正是緩存可成功應用的場合。我建議使用啟用了事務間緩存的樂觀鎖定。如果數據庫模式可更改，我通常指定一個verify-columns的整型值，如果數據庫模式不可更改，就指定一個Modified值。如果您決定使用一個版本列，那么要保證外部進程(如果有的話)在數據發生變更時遵守版本列更新的協定;否則，面臨更新丟失的風險。

　　從選擇適當的緩存大小方面來看，應該考慮多版本化，以及從finder方法返回的最大bean數目。一個不錯的上限估計方法是將應用程序需要同時處理的最大事務數乘以單個事務可以處理的最大bean數。我通常建議使用更加靈活的應用程序級緩存，因為通常不太可能所有的CMP都同時被使用。應用程序緩存對于所有CMP來說是全局的，會自適應不同bean的活動。如果您定義了一個過大的應用程序級緩存，可能會損害性能，因為所有事務都會串行訪問這個唯一的緩存。對于大小適當的緩存來說極少出現這個問題，但是同樣，在您不確定緩存大小如何影響性能時應該進行性能測試。順便說一下，良好的設計實踐是，避免創建返回任意多實體bean的finder方法(比如，大型表上的findAll())，因為這使得估計出適當的緩存大小變得幾乎不可能。

　　帶有事務間緩存的樂觀并發最適合有緩存碰撞“保護”的用例。比如，在一個項目用例中，應用程序需要處理傳入消息(來自JMS)。每個消息記錄需要在數據庫表中創建，然后必須發送另一個消息作為響應;對于第二個消息來說，應用程序希望在一分鐘內收到響應，并且在收到該響應時，同一條數據庫記錄得到更新。這時在該場景中應用緩存會帶來巨大和直接的性能收益。我們“保證”每個被緩存的項目至少有一個碰撞，如果緩存對于保存CMP實例來說過大的話。

　　另一個極端是目標表太大，以至于不可能對同一數據作出重復請求。從實踐角度來看，這是不可行的，并且緩存這樣的數據不能提高性能。

　　在上述的read-mostly模式中，樂觀并發模式應該是更好的選擇。read-mostly模式不能用于集群中，不能防止出現更新丟失，并且一般來說不便于使用。本文講述它是為了提供關于所有可用策略的整體情況，但是我不鼓勵在現代應用程序中使用它。

　　Read-mostly數據

　　如果您的應用程序主要是插入或更新記錄，那么緩存數據意義不大，因為幾乎不會再次訪問它們。在只進行插入操作(OLTP)的極端情況下，緩存反而會減慢處理速度。非重復性更新(對表中遠超過緩存大小的隨機行的更新)也很少從CMP緩存中受益。此外，隨著更新數目相對于讀取次數的增加，樂觀并發策略的表現越來越差，因為會出現大量的樂觀并發異常。實際上，如果您的應用程序只在數據庫中更新和插入記錄，就根本沒有必要使用實體bean。

　　結束語

　　從本文的長度就可以看出，調整CMP 2.0 EJB有很多內容。我首先講述了可用的各種并發策略。然后討論了一些重要的性能策略：read-mostly模式，事務間緩存，以及選擇最佳緩存大小。最后，我提供了關于在何種情況下使用何種策略的指南。我希望這些分析能幫助你更好地理解EJB。

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