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

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

  　J2EE規范現在作為同時期企業項目的標準被廣為接受。但是J2EE規范的一個重要部分即EJB持久性由于它的開發模型復雜并且實體bean的性能很差而長期受到批評。人們相信這樣一個事實：如果實體bean(尤其是容器受控持久性實體bean，或者CMP)用于應用程序中，那么性能將受到影響。事實并非如此。

　　本文中我不打算解釋EJB的復雜性。即將推出的EJB 3規范專門針對目標和開發模型，使得它更容易;該規范還提供依賴注入以及在實體bean容器之外的更容易的測試。相反，本文的目標在于提供BEA WebLogic Server 8.1和9.0中可用的高級選項的深度分析，使開發人員改善CMP bean的性能——在很多情況下可極大地改善。該主題很寬泛，不可能在一篇文章中一一涉及;因此，我只重點討論CMP實體bean的并發以及長期緩存策略。我還簡要說明了最新版本BEA WebLogic Server 9.0中的改進。

　　并發策略

　　J2EE開發人員知道EJB容器維護了一個實體bean緩存或者池，通?？稍诓渴鹈枋龇信渲?。令人驚奇的是，相當多的J2EE開發人員不知道這并不意味著一旦J2EE服務器從數據庫中加載一個特定的bean實例，它就不再去數據庫中尋找該實例，因為該實例已經保存在緩存池中了。相反，默認情況下J2EE服務器執行ejbLoad()在每次事務的開始從數據庫中同步該實例的狀態?；旧?，CMP bean每運行一次(即使該bean在前一個事務中已經被加載)，服務器就執行一次SQL select語句來刷新它。只有在一個事務中操作多個實體bean實例時，服務器才會緩存它們。

　　顯然，在每次事務中都重新從數據庫中加載狀態會造成很大的性能影響!這個默認行為很容易理解：如果數據庫被多個進程共享，并且每個進程都可以改變數據庫中持久對象的狀態，那么這將是最安全的方法。但是可以通過告訴J2EE服務器保留事務間實體bean的緩存實例，從而避免大部分時間里從數據庫中刷新數據來略微改善這種情況。為了解決這個問題并生成一個最優的解決方案，首先我將討論BEA WebLogic Server中可用的不同的并發策略。

　　對于EJB開發人員來說很重要的一點是要知道實體bean中可用的不同并發策略。令人驚奇的是，有的開發人員甚至不知道并發選項的存在。那么適用于實體bean的并發策略是什么呢?EJB容器是一個高度多線程的應用程序，同時響應來自多個客戶端的請求，這些請求通常會訪問同一資源，比如數據表中的一行。因此，EJB容器應該管理對實體bean實例的并發訪問;更加技術性地講，并發策略決定了容器如何以及何時將實體bean的每個實例與底層數據庫同步。

　　目前WebLogic Server中有四種可用的并發策略：排他、數據庫、樂觀和只讀。默認情況下，從7.0版本開始，WebLogic Server就使用的是數據庫并發。上面四種策略按性能從低到高依次排列。我將討論每種策略的優缺點。

　　排他性并發

　　排他性并發意味著容器最多為每個主要鍵值創建一個實體bean實例(比如，表中的一行映射到容器中的一個EJB實例)。對指定實例的訪問是串行的，并且請求是按照順序逐個執行的。這種策略有一些嚴重的問題。首先，性能由于多個客戶端對bean的串行訪問受到明顯影響，并且您不能再考慮應用程序的伸縮性。其次，EJB的單個實例(以及容器持有的關聯鎖)對于一個JVM(一個服務器實例)來說是本地的，不能在集群中工作。該策略只是用于后向兼容(早期版本的WebLogic Server默認使用它)，應該盡量不用。

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