Seven Rules for Optimizing Entity Beans

最佳化Entity Beans的七條原則 (自已翻譯的老文章 )

Entity beans提供了一個清晰的模型，它描述了應用當中持久的商業對象和這些對象的設計構思。在物件模型中，簡單的Java對象通常用最直接了當的方法來描述，但這沒有包括在商業對象中常常需要用到的事務持續管理功能。Entity Beans不僅允許在一個物件模型中有相同類型商業對象的建模和考慮，而且也在bean和container服務後面隱藏所有複雜性的同時封裝了持久機制。這將允許應用程式以Java對象的形式去操作這些Beans。對於任何調用代碼，持久的形式和持久機制都是隱藏了的。Entity beans允許container創造性的進行最佳化持久，在遵守資料存放區的開放和靈活的同時，沒想到決定部署時間。

以EJB為基礎的項目開發，大量使用了物件導向方法和entity bean，Sun的工程師已經掌握在真實世界中使用entity beans。這篇文章詳細閘述了如下的開發經驗：

·探究不同的最佳化方法
·提供關於達到最佳效能和靈活性的建議和標準
·討論如何避免一些已知的危險

Use Container-Managed Persistence When You Can(儘可能的使用CMP)
不要認為CMP只是用來以寫少量代碼來減輕工作的方法，它也是container最佳化EJB的方法，並讓container自動產生的資料庫存取代碼。Container通過訪問bean的記憶體緩衝區實現監控緩衝區的任何變化（也就是監控bean的變化）。在一個事務提交之前儲存緩衝區到資料庫，避免了緩衝區在沒有任何改變時對其進行儲存操作，也就避免了不必要的資料庫調用而產生的昂貴開銷。

另一個最佳化的建議是關於find方法的調用。尋找一個entity bean通常包括兩個資料庫操作：
·尋找資料庫中的一條記錄並取得它的primary key.
·取得這條記錄將其放到緩衝中

CMP允許最佳化這兩個資料庫操作，使它們成為一個操作，無論何時都是有意義的，它可以在一個資料庫調用中同時取得primary key和記錄資料。

Write Code that Supports Both Bean- and Container-Managed Persistence(編寫對BMP和CMP都支援的代碼)
很多案例中，EJB的作者沒有控制到EJB在部署時，container是否將支援CMP。同樣，部署人員最終可能選擇在container中使用BMP方式。你必須找到一個實現方法，讓beans在允許BMP部署時又不會因為需要支援更多可能的CMP最佳化機制時發生混亂。一個方便的方法可以實現這個目標，就是將純商業邏輯從持續機制中分隔出來。商業邏輯的實現在你的CMP類中，它能在選擇CMP方式時單獨部署。這樣，將持續代碼放到BMP類中，將其從CMP的類中進行繼承。這樣就做到了CMP超類中包含所有的商業邏輯，而BMP子類中則包含了資料庫存取代碼，1。
Figure 1: Separation between CMP and BMP

這個模型非常容易實現，但仍使靈活性受到了抑制：
它不可能從implementation classes中繼承。
因為這樣做意味著子類必須從CMP和BMP這兩個超類中同時直接繼承。另外，BMP子類將不得不直接成為CMP的實現。這就導致了多重類繼承，2，Java編程中是不允許多重繼承的。
Figure 2: Multiple inheritance not supported in Java

沒有簡便的方法來支援變化的持續執行。
如果可以的話，這將非常有用，如為不同的資料庫供應商或不同類型的資料庫執行包含資料庫特殊代碼。（如關係型、對象型，和其他一些舊類別的資料庫）

要解決這些問題，你需要改變當前BMP的類模型，委託BMP類中的所有的持續代碼給一個輔助類，並且去除BMP類中的架構。輔助類的類型被稱為DAO（Data Access Object資料存取對象）。你能讓DAO的interface中提供多個DAO的子類，這樣就允許正確的DAO子類被執行個體化。3.這裡有很多種方法來選擇和執行個體化正確的DAO子類，比如，可以通過讀取環境入口或者通過瞭解資料庫類型來選擇最合適的子類。
Figure 3: Delegation and allowing for alternate DAO implementations

 

使用這個類型，CMP實現和包含實現的DAO都能輕易的進行擴充（繼承）；可以從BMP的類中繼承任何東西！因為這些BMP的類包含了看起來幾乎相同的所有entity bean中授權的基礎代碼，並且執行個體代碼會選擇正確的DAO對象，你只需要做一點點的修改，就能方便的將一個bean複製成一個新的bean。同樣，你最終可以做到用一個工具來自動產生它們！

當通過繼承一個entity bean來重用另外一個bean所提供的邏輯時，這不會使EJB1.1規範允許通過擴充entity的類型來擴充home 介面。Finders和create的調用在理論上始終是遠程調用。產生的殘餘代碼（stubs？）將永遠不會描述為一個子類型，儘管邏輯上可以（比如，把它們作為一個factory方法）。這阻止了在參照EJB1.1規範的EJB實現中使用很多有用的設計模式。

Minimize Database Access in ejbStores(在ejbStores中最小化資料庫存取)
當使用CMP時，bean絕對不能控制ejbStore，它將所有的最佳化操作交給了container。由container來提供的CMP最佳化是快速container和慢速container區別的要素。

只要bean使用BMP來部署，對操作緩衝區變化標誌來說是非常有用的。緩衝區的所有改變將可以通過ejbStore中設定這個標誌來判斷。如果標誌沒有被修改，則意味著緩衝區沒有被改變，ejbStore正就這樣跳開了所有資料庫存取的開銷。這個決竅對於這些經常進行查詢而很少進行更新的beans來說尤其有用的。它們通常是很多應用的大部分組成（如表尋找）。

這個方法有個需要注意之處。當這個標誌因資料庫存取而被修改時，它將適合放在BMP方式的代碼當中。在以前面所說到的模式實現時，將這個標誌放在BMP代碼架構上或者放在DAO中。因為DAO在調用商業方法時從未被調用，它們不是標誌需要放的正確位置，應該將標誌放到BMP架構代碼中。這個天性使得BMP代碼更加複雜難懂，因為商業方法需要委託超類進行重載。

理論上，EJB的作者將不會不得不處理系統級的問題，如緩衝區操作。不幸的是，EJB1.1使BMP不能提供任何為最佳化所做的折衷的方法，因此bean的作者仍不得不手工設定資料庫改變標誌。

Always Cache References Obtained from lookups and find Calls(將lookups和find調用取得的References緩衝)
    
Reference Caching對於entity beans和session beans都是有用的。JNDI要尋找EJB 資源，如DataSources，bean References，或者連環境入口也能公平的開銷？，並且簡單的做到避免進行多餘的lookup。要解決這個問題，需要：
·將這些references定義成執行個體變數
·在setEntityContext中找到它們（session beans中是setSesssionContext方法）
SetEntityContext方法只是在執行個體化bean時調用一次，因此在此時尋找所有需要的references不會有真正的開銷。避免在任何其他方法中尋找references，尤其是對資料庫進行存取的方法，ejbLoad和ejbStore。一些方法會被頻繁地調用，導致大量的時間花費在無意義的lookup調用上。

在調用一些entity beans的finders方法時這也是非常重要的，當這些調用可能適合或不適合bean初始化回調時（如setEntityContext），就可以緩衝由finds方法產生的references結果，這在任何時候都是適用的。由finder方法的多餘調用產生的開銷是非常高的。如果reference只對當前entity有效，你需要在執行個體描述其他實體（entites）開始重新活動之前清除references。這需要在ejbActivate方法中完成。

Always Prepare Your SQL Statements(總是使用Prepare的SQL語句)
這種最佳化方法對於使用SQL存取關聯式資料庫的所有代碼都有用。目前大多數的EJB使用關聯式資料庫實現，這個標準對於bean作者不得不編寫資料庫存取代碼進行EJB開發也是非常有用的。

對於每一條被資料庫處理的SQL語句，資料庫都需要在執行這條語句之前對其進行編譯。好的關聯式資料庫，無論如何，能夠緩衝語句和它的編譯形式，並將新語句與相對於從緩衝中取得的語句編譯形式進行匹配。無論如何，為了使用這種最佳化方法，新的語句必須正確的匹配舊的語句。

·Non-prepared 語句:對於non-prepared語句，資料和語句本身是在同一個字串中傳送，儘管語句在後來的調用中看起來是一樣的，但資料並不一樣，從而不能被最佳化。
·Prepared語句:對於prepared語句，只傳送了沒有資料的語句到資料庫，而從緩衝中取得形式（form）

當你在使用語句時，資料傳送到語句，語句開始執行。通常，語句在準備（prepare）時被編譯，但後繼的prepares已經匹配了緩衝中的語句，而且不需要重新編譯。這項技術提升了非常高的語句（statement） cache命中率，最小化了語句（statement）的編譯總數。對於小型資料庫的存取，它能減少90％以上的語句執行時間！

Close all Statements Properly(關閉所有Statements)
當在BMP實現中處理資料庫存取代碼時，絕對不要在資料庫存取調用之後開啟語句（statement）。每開啟一個statement相應的在資料庫中開啟一個遊標。（當垃圾收集器終於要求開啟statement，並在垃圾收集時關閉它時，你不能控制垃圾收集器開啟的時間。不要通過System.gc的方法強迫垃圾收集器）不關閉Statement將導致資料庫過多的開啟遊標，消耗資料庫資源的操作相反可以利用它來改進資料庫的效能。

同樣，確認在關閉statements時完全捕捉所有例外。在一個閉環的statement中的例外必須不影響到其他statements，使其被忽略和只有開啟沒有關閉。

Avoid Deadlocks(避免死結) 

應用程式代碼不可以直接控制ejbStore（或者等價於CMP）何時被調用。這由Container決定什麼時候調用，通常在事務最後被調用。

如果多個entity beans或多個實體（eitities）涉及到一個事務，ejbStore被調用的順序是不可定義的。這也意味著使用者不能控制描述這些實體（entities）的資料庫記錄的存取/鎖定順序。當多個表/行涉及到一個混和鎖定命令非常有可能導致死結。

從完美的、理想的一面來看，container能夠控制EJB中的存取和鎖定，也就能夠解決死結，並且消除了開發人員/部署者的諸多疑慮。不幸的是，當前幾乎沒有任何有效商業性質的應用程式伺服器能夠在處理資料庫鎖的方面做得很好，只能將複雜entity bean部署中死結的問題留給部署者。

可應用的標準，至少在寫這篇文章時，假設container將以相同順序調用beans中的資料庫存取調用，這個beans的事務方法是事務中第一個被存取的部分。更清楚的認識請思考以下的例子：假設entity bean EB1有一個事務方法 m1，entity bean EB2有一個事務方法 m2。如果在一個事務當中，EB1.m1在EB2.m2前被調用，也可假設EB1.ejbLoad在EB2.ejbLoad之前被調用，並且EB1.ejbStore也在EB2.ejbStore之前被調用。這意味這個實體或資料庫記錄描述的EB1是在EB2之前被鎖定的。要避免死結，確認在貫穿整個應用程式的任何事務當中EB1永遠在EB2之前被調用。

當應用程式伺服器變得越來越聰明且知道如何命令資料庫存取時，EJB作者和部署者將可能放心bean的存取順序了。無論如何，代碼要嚴格的處理調用順序，象例子中提供的，要做到像今天這樣能繼續在未來的伺服器上運行。

Going Forward
利用這些標準，在實體-加強器(entity-intensive)開發時和部署時，對增加beans的效能和靈活性有另人矚目的協助，允許在最小化它們在container和底層系統的載入時，讓它們去適應不同的持久的儲存類型。這將讓部署者靈活的選擇大多數相配的部署基礎結構，並且允許beans有效使用基礎結構所提供的功能。換句話說 – 一次編寫隨處運行，高效。

For More Information
Enterprise JavaBeans downloads and specifications
jGuru's Enterprise JavaBean Fundamental short course
Recent Java Developer articles on Enterprise JavaBeans
The ECperf workload