我作為BEA的顧問，已經成功地幫助客戶在各種版本的WebLogic Server (WLS)上設計並部署了應用程序。BEA從EJB 1.0已經開始支持容器管理（CMP）的實體beans，並且已有一些客戶在使用它們。可不幸的是，一些客戶在不理解實體bean的情況下就使用上了它們；而另一些客戶一聽說它會對性能有某些約束，就完全從他們的結構/設計選擇上排除使用實體beans。 當面對系統分析師的詢問"我究竟何時應該考慮去使用CMP方式的實體beans呢？"的時候，我很難解釋為什麼要使用CMP形式的實體beans。實體beans的優勢體現在兩方面：高速緩存和對象－關系的映射。兩者在先前的版本中都勉強的被實現，但EJB 2.0拯救了這種情況。WLS 7.0在EJB 2.0規范上的附加功能彌補了在使用實體beans和使用無狀態會話beans之間在性能方面的差距，說明：無狀態會話bean是通過DAO和JDBC訪問數據庫的，在某些情況下實體bean甚至比無狀態會話bean執行的快。當使用JDBC時，強烈建議開發者使用容器管理的事務。 早期版本的問題 一些在過去使用實體beans的客戶不得不重新設計和使用JDBC，因為他們的系統太慢以至於無法滿足服務。緩慢的原因在於： 沒有高速緩存： 每個事務為了加載實體bean都訪問數據庫。客戶在使用實體bean時所期望的承諾之一是緩存，而對規則實體beans來說在集群環境中是沒有緩存可以使用的。 單一表支持 (O-R 映射過分簡單化)： 客戶也期望對象－關系映射可以由實體bean完成，但是由容器提供映射功能過分簡單了。 每個虛擬機（VM）只能有該實體bean的單一實例：由於WebLogic 5.1和更低的版本只支持互斥鎖，所有對實體bean的調用都是串行化的，這樣會引起系統瓶頸甚至是對只讀beans。 互斥鎖 ：當一些beans在使用事件而另一些沒使用的時候，死鎖發生的可能性很高。 單一setX調用：這引起整個實體bean都被寫進數據庫。在EJB 2.0 規范前，容器對於判斷哪些內容發生了改變哪些沒有發生改變是沒有辦法的，這意味著在ejbStore時，所有的屬性都要更新。 裝載 ：裝載實體bean，使所有的數據成員都裝進內存，只需要幾個的時候。 無動態查詢 ：寫了一個新的查詢時，EJB必須被重新部署。 查詢 ：查詢會實例化大量的實體beans，消耗內存並且降低系統性能。 WLS 7.0的特征 WLS 7.0 實現了在EJB 2.0中提供的豐富的對象－關系映射規范。在優化讀寫數據庫方面EJB 2.0也為容器提供了更豐富的便利。下面說明了開發者在WLS 7.0 中設計實體beans方面所擁有的豐富和靈活的特征。 容器管理的關系 ：實體beans可以關聯其他的beans；這些關系可以是雙向的或是單向的。WLS支持三種類型的關系映射，由WebLogic CMP管理：一對一，一對多，多對多。 一個實體bean的多表映射：多表的支持允許一個符合EJB 2.0特征的CMP beans的實現器將一個EJB 映射為一個據庫中的多DBMS表。 調優EJB2.0的寫操作：當調用ejbStore時只更新寫進數據庫的字段，而不是把所有字段都寫進數據庫。 使用字段組調優讀操作：在ejbLoad容器，只裝載fIEld-group中的字段，而不是裝載實體bean的所有字段。 關系的緩存： 這個特征提高實體bean的性能，通過在某一個聯合查詢（非多重條件查詢）中緩存並裝載相關的beans。 實體beans可以返回ResultSets（記錄集）：WLS 支持ejbSelect()查詢，它在Java.sql.ResultSet的表單中返回多列的查詢結果。 對不同種類的實體beans的應用級的緩存： 代替對每個實體bean分散的緩存，這個特征可以使多個實體beans 在一個EAR中共享一個單一運行時的緩存。 動態查詢： EJB 2.0規范強制用戶在部署描述符中編寫查詢代碼。通過采用動態查詢，新的查詢可以通過程序被構造和執行而不用重新部署beans。 Read-mostly設計模式：在現實世界中，大部分應用程序的90% 為讀取而10%為更新。實體bean可以被寫成模擬數據並且可以部署為只讀實體bean和規范的實體bean。通過這種方法，想要讀取數據的用戶與只讀實體bean交互，而想要修改數據的用戶與規則的實體bean交互。當修改發生時，容器使所有的只讀實體bean失效，當數據訪問再次發生時迫使容器調用ejbLoad。 其他有用的特征包括：自動生成主鍵，支持級聯刪除，支持EJB QL（Query Language，查詢語言），ejbSelect方法，以及下面所描述的並行策略。 並行策略 並行策略定義一個實體bean創建多少實例，為了維持事務的完整性誰來實現同步以及在實體bean中的數據模型存取模式。恰當的並行策略可以使實體bean在性能上產生極大的不同。 互斥性：對於每個VM實體bean容器只產生一個實例，所有實體bean的調用都作為使用容器鎖的實體bean來串行化。這絕不被推薦使用。 數據庫：容器延期對數據庫的鎖定，並且每個事務都有它自己實體bean的拷貝。ejbLoad 和 ejbStore 在各自事務的開始和結束時被調用。 只讀實體beans： 數據庫和容器都不支持任何的鎖，每個事務得到它自己的實體bean的拷貝。一個叫做
的可配置參數用於控制實體bean調用ejbLoad方法。EjbStore在實體bean上永遠不會被調用。客戶端仍然可以在實體bean上進行創建，移除和更新操作。創建和移除操作會成功，而由於不調用ejbStore，更新操作將不會修改數據庫。在只讀實體bean上不調用CUD(create, update, delete)方法是程序員的責任。只讀實體bean對於"分布式緩存"問題是最好的解決方法。 開放式的實體beans ：容器延期對數據庫的鎖定，但是該鎖在事務期間不予以保留。其基本思想是容器在提交前檢查修改了的數據並且如果其他人也修改了數據時，將該操作回滾。如果你想有比TX_READ_COMMITTED更高的一致性，而不需要達到TX_ SERIALIZABLE那麼高的一致性時這樣做是很有用的。如果你能忍受短時間讀取陳舊的數據，而又想完成一些update操作的事務完整性時，你可以使用它。這裡有四個選項可用於檢查optimistic式沖突： 1． 檢查讀取的列 2． 檢查修改的列 3． 檢查時間信息列 4． 檢查版本信息列 選項3和4是不被推薦的，因為為適應這個並行策略，表的結構需要改變。同樣，對於開放式並行策略，你可以配置在事務為true和false期間你是否需要緩存。對在事務期間設置為false的緩存，將在每個事務開始的時候調用ejbLoad。 比較 對於CMP，總要有附加處理過程的，這是由於在EJB容器以及容器層上（合成碼）有一個集成，該容器層用於處理事務、安全、池態、生命周期管理、failover、緩存和關系。這裡。CMP（由設計或由規范）必須做一些內部操作（ejbLoad, ejbStore, ejbActivate, ejbPassivate）就像反對JDBC邏輯而由開發者自己手寫編程。容器基礎結構的好處是優化並生成數據庫訪問；加速開發以及簡化代碼維護。在我見過的基准上，除非數據是被緩存了的， [stateless session bean + DAO (做 JDBC訪問)] 執行比實體bean執行快30-50%。 什麼時候使用什麼 實體bean不能用來取代編寫JDBC。如果你的對象－關系模型不是極度復雜（包括許多連接，等等）和靈活並且對於工程代碼的維護比速度更重要時可以使用實體beans。使用JDBC於簡單的，原子級別綁定的更新；使存儲過程和觸發器相結合；並處理大量的ResultSets（記錄集）。 WebLogic附加的功能例如read-mostly設計模式和開放式緩存cache-between-transactions設置成true是兩種設計選擇，它使實體beans成為吸引人的選擇。它們都是BEA所特有的屬性，在WebLogic特殊部署描述符中指定的。當轉移到另一個適用J2EE的應用服務器上時無需代碼變更。對於應用來說通過使用開放式緩存並行策略可以在短時間讀取舊的數據。對於大多數在讀取而少數時候更新的用例，使用read-mostly設計模式。這種設計模式也有缺點，就是用戶會讀取到過時的數據。對於一些用戶完全不應讀取過時的數據的情況，他們可以從讀寫bean讀取。 CMP實體beans的只讀實體beans的特征將在以後發布的EJB規范版本中有所提及。使用只讀實體beans來實現一個可以周期性更新的分布式緩存。 結論 現實世界中大多數的應用程序的讀操作比寫操作多很多。現實中read-mostly模式對兩種情況來說都將是最好的方法。它提供簡單的開發和靈活的部署，並且對於存取數據提供卓越的性能特性，只有當數據被修改時才會有的額外開銷。cache-between-transactions設置成true的開放式的並行可以比JDBC還快。編寫最優化的SQL對於正規的Java程序員來說很難，所以不要忽略實體beans的價值並決定它們是否最適合。 實體Beans的例子 提供的示例在BEA-HOME/samples/server/src/ejb20子目錄下。 論證關系的示例參看BEA-HOME/samples/ server/src/ejb20/relationships/bands目錄。 論證多表映射的例子參看BEA-HOME/ samples/server/src/ejb20/multitable 目錄。 使用數據庫並行選項在weblogic-ejb-jar.XML中指明Database 使用只讀並行選項在weblogic-ejb-jar.XML中指明Read-only 使用開放式並行cache-between-transactions並且檢查改進的選項在weblogic-ejb- jar.XML中指明Optimistic True並且在weblogic-cmp-rdbms -jar.XML中指明ModifIEd。實現"read-mostly"設計模式注冊bean的實現就像兩個EJBs，一個作為只讀另一個作為可讀寫的，並且在weblogic-ejb -jar.XML中ejbname是只讀實體bean名字處添加ejbname 。 參考 http://edocs.bea.com/wls/docs70/ejb/index.Html http://Java.sun.com/products/ejb/docs.Html
