WebLogic Server中CMP實體bean的性能調優[5] 軟件測試
使用read-mostly模式
WebLogic Server通過將一個只讀CMP bean和一個讀寫CMP bean映射到同一數據中為您提供了一個實現read-mostly模式的機制。您的應用程序應該用只讀bean來讀取數據，用讀寫bean來修改數據。只讀bean按照上述部署描述符中read-timeout-seconds元素所指定的間隔從數據庫中加載數據。為了保證只讀bean總是返回當前數據，應該在讀寫bean更改數據時使只讀bean無效。您可以通過在weblogic-ejb-jar.xml中的entity-descriptor小節的invalidation-target元素中指定該bean，來配置服務器，使其自動讓相應的只讀bean無效。這只能用于CMP 2.0實體bean。雖然該模式提供了緩存方面的好處，但是也有嚴重的不足。當使用該模式時，您應用程序中的大量實體bean將被有效地加倍，對應用程序的啟動時間和內存造成影響。同樣，開發人員需要記住，只讀和讀寫操作應該使用不同的bean，這經常會令人混淆。
值得一提的是，在舊版本的WebLogic Server中(沒有對只讀模式的通過invalidation-target的內在支持)，仍可以使用它�；貞浺幌虑懊嬷v過的，根據EJB規范，如果EJB拋出一個RuntimeException或者它的子類物，容器就應該銷毀bean實例。因此，可以在實體bean的只讀版本上暴露這樣的destroyMe()方法，并從讀寫bean的ejbStore()方法中調用它。這就是著名的sepukku模式。
在讀/寫CMP bean的事務間緩存
另一種更先進的長期緩存的方法是通過將weblogic-ejb-jar.xml中的cache-between-transactions元素設置為true來配置bean。這種情況下，只有客戶端首先引用該bean或者事務被回滾時WebLogic Server才會調用ejbLoad()來從數據庫中加載數據。
盡管從理論上說，您可以對除數據庫并發之外的所有并發策略使用該方法，但是在實踐中，只有對樂觀并發使用該方法才有意義。當應用于只讀并發時，該設置被忽略，因為bean數據已經被緩存;當應用于排他性并發時，只有EJB具有對底層數據庫的排他性訪問時才起作用，而這是極少出現的情況。此外，當具有排他性并發的bean被部署在集群中時，WebLogic Server自動禁用事務間的緩存，因為集群中的任何服務器都可能更新bean數據，并且沒有用來在節點間同步或禁用緩存值的機制。這使得我們在進行長期緩存時只有一種可行的并發策略：樂觀并發。
如前所述，對于利用樂觀并發策略部署的bean，WebLogic Server有一種內在機制，用來通過verify-columns檢測底層數據變更。雖然樂觀并發本身只能為數據庫并發帶來少量性能改善，但可利用事務功能間的緩存提供更大的改善。如果在EJB緩存中bean實例已經可用的話，將cache-between-transactions設置為true將使WebLogic Server忽略對數據庫的調用。對于某些類型的應用程序(其中同一對象在短期內被不同事務多次訪問)，這可能導致顯著的性能改善(在某些環境下，最多百分之30到40)。自然地，既然我們使用的是樂觀并發，您的應用程序必須做好在檢測到并發沖突時處理OptimisticConcurrencyException的準備。當OptimisticConcurrencyException(RuntimeException的子類型)被拋出時，WebLogic Server 從緩存中丟棄一個EJB實例。注意，如果您將delay-updates-until-end-of-tx設置為true(默認)，除非事務承諾否則就得不到樂觀異常，并且如果使用的是容器受控事務這將在應用程序代碼之外。
與read-mostly模式(不提供通知集群中其他節點其中一個節點的數據發生變更的機制)相比，當具有樂觀并發的bean被更新時，一個通知將被廣播給其他集群成員，并且緩存bean實例將被丟棄，以避免樂觀沖突。由于WebLogic Server不廣播數據變更本身，而是只廣播某些種類的bean標識符，這種跨集群的緩存無效措施在提高性能和網絡帶寬利用率方面很有效。WebLogic Server自動完成這種緩存無效工作，bean開發人員不需要再做其他配置。當對同一個bean發出下一個請求時，新鮮的數據將被從數據庫中加載。
文章來源于領測軟件測試網 http://www.kjueaiud.com/