我作為BEA的顧問
已經成功地幫助客戶在各種版本的WebLogic Server (WLS)上設計並部署了應用程序
BEA從EJB
已經開始支持容器管理（CMP）的實體beans
並且已有一些客戶在使用它們
可不幸的是
一些客戶在不理解實體bean的情況下就使用上了它們
而另一些客戶一聽說它會對性能有某些約束
就完全從他們的結構/設計選擇上排除使用實體beans
當面對系統分析師的詢問
我究竟何時應該考慮去使用CMP方式的實體beans呢？
的時候
我很難解釋為什麼要使用CMP形式的實體beans
實體beans的優勢體現在兩方面
高速緩存和對象－關系的映射
兩者在先前的版本中都勉強的被實現
但EJB
拯救了這種情況
WLS
在EJB
規范上的附加功能彌補了在使用實體beans和使用無狀態會話beans之間在性能方面的差距
說明
無狀態會話bean是通過DAO和JDBC訪問數據庫的
在某些情況下實體bean甚至比無狀態會話bean執行的快
當使用JDBC時
強烈建議開發者使用容器管理的事務
早期版本的問題
一些在過去使用實體beans的客戶不得不重新設計和使用JDBC
因為他們的系統太慢以至於無法滿足服務
緩慢的原因在於
沒有高速緩存
每個事務為了加載實體bean都訪問數據庫
客戶在使用實體bean時所期望的承諾之一是緩存
而對規則實體beans來說在集群環境中是沒有緩存可以使用的
單一表支持 (O
R 映射過分簡單化)
客戶也期望對象－關系映射可以由實體bean完成
但是由容器提供映射功能過分簡單了
每個虛擬機（VM）只能有該實體bean的單一實例
由於WebLogic
和更低的版本只支持互斥鎖
所有對實體bean的調用都是串行化的
這樣會引起系統瓶頸甚至是對只讀beans
互斥鎖
當一些beans在使用事件而另一些沒使用的時候
死鎖發生的可能性很高
單一setX調用
這引起整個實體bean都被寫進數據庫
在EJB
規范前
容器對於判斷哪些內容發生了改變哪些沒有發生改變是沒有辦法的
這意味著在ejbStore時
所有的屬性都要更新
裝載
裝載實體bean
使所有的數據成員都裝進內存
只需要幾個的時候
無動態查詢
寫了一個新的查詢時
EJB必須被重新部署
查詢
查詢會實例化大量的實體beans
消耗內存並且降低系統性能
WLS
的特征
WLS
實現了在EJB
中提供的豐富的對象－關系映射規范
在優化讀寫數據庫方面EJB
也為容器提供了更豐富的便利
下面說明了開發者在WLS
中設計實體beans方面所擁有的豐富和靈活的特征
容器管理的關系
實體beans可以關聯其他的beans
這些關系可以是雙向的或是單向的
WLS支持三種類型的關系映射
由WebLogic CMP管理
一對一
一對多
多對多
一個實體bean的多表映射
多表的支持允許一個符合EJB
特征的CMP beans的實現器將一個EJB 映射為一個據庫中的多DBMS表
調優EJB
的寫操作
當調用ejbStore時只更新寫進數據庫的字段
而不是把所有字段都寫進數據庫
使用字段組調優讀操作
在ejbLoad容器
只裝載field
group中的字段
而不是裝載實體bean的所有字段
關系的緩存
這個特征提高實體bean的性能
通過在某一個聯合查詢（非多重條件查詢）中緩存並裝載相關的beans
實體beans可以返回ResultSets（記錄集）
WLS 支持ejbSelect()查詢
它在java
sql
ResultSet的表單中返回多列的查詢結果
對不同種類的實體beans的應用級的緩存
代替對每個實體bean分散的緩存
這個特征可以使多個實體beans 在一個EAR中共享一個單一運行時的緩存
動態查詢
EJB
規范強制用戶在部署描述符中編寫查詢代碼
通過采用動態查詢
新的查詢可以通過程序被構造和執行而不用重新部署beans
Read
mostly設計模式
在現實世界中
大部分應用程序的
% 為讀取而
%為更新
實體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式沖突
． 檢查讀取的列
． 檢查修改的列
． 檢查時間信息列
． 檢查版本信息列
選項
和
是不被推薦的
因為為適應這個並行策略
表的結構需要改變
同樣
對於開放式並行策略
你可以配置在事務為true和false期間你是否需要緩存
對在事務期間設置為false的緩存
將在每個事務開始的時候調用ejbLoad
比較
對於CMP
總要有附加處理過程的
這是由於在EJB容器以及容器層上（合成碼）有一個集成
該容器層用於處理事務
安全
池態
生命周期管理
failover
緩存和關系
這裡
CMP（由設計或由規范）必須做一些內部操作（ejbLoad
ejbStore
ejbActivate
ejbPassivate）就像反對JDBC邏輯而由開發者自己手寫編程
容器基礎結構的好處是優化並生成數據庫訪問
加速開發以及簡化代碼維護
在我見過的基准上
除非數據是被緩存了的
[stateless session bean + DAO (做 JDBC訪問)] 執行比實體bean執行快
%
什麼時候使用什麼
實體bean不能用來取代編寫JDBC
如果你的對象－關系模型不是極度復雜（包括許多連接
等等）和靈活並且對於工程代碼的維護比速度更重要時可以使用實體beans
使用JDBC於簡單的
原子級別綁定的更新
使存儲過程和觸發器相結合
並處理大量的ResultSets（記錄集）
WebLogic附加的功能例如read
mostly設計模式和開放式緩存cache
between
transactions設置成true是兩種設計選擇
它使實體beans成為吸引人的選擇
它們都是BEA所特有的屬性
在WebLogic特殊部署描述符中指定的
當轉移到另一個適用J
EE的應用服務器上時無需代碼變更
對於應用來說通過使用開放式緩存並行策略可以在短時間讀取舊的數據
對於大多數在讀取而少數時候更新的用例
使用read
mostly設計模式
這種設計模式也有缺點
就是用戶會讀取到過時的數據
對於一些用戶完全不應讀取過時的數據的情況
他們可以從讀寫bean讀取
CMP實體beans的只讀實體beans的特征將在以後發布的EJB規范版本中有所提及
使用只讀實體beans來實現一個可以周期性更新的分布式緩存
結論
現實世界中大多數的應用程序的讀操作比寫操作多很多
現實中read
mostly模式對兩種情況來說都將是最好的方法
它提供簡單的開發和靈活的部署
並且對於存取數據提供卓越的性能特性
只有當數據被修改時才會有的額外開銷
cache
between
transactions設置成true的開放式的並行可以比JDBC還快
編寫最優化的SQL對於正規的Java程序員來說很難
所以不要忽略實體beans的價值並決定它們是否最適合
實體Beans的例子
提供的示例在BEA
HOME/samples/server/src/ejb
子目錄下
論證關系的示例參看BEA
HOME/samples/ server/src/ejb
/relationships/bands目錄
論證多表映射的例子參看BEA
HOME/ samples/server/src/ejb
/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
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25612.html
