^{<style id="v7see"></style>}

優化entity Bean的七條準則

2019-11-18 12:28:39

字體：大中小

來源：轉載

供稿：網友

　　entity bean為在應用程序和設計中描述持久化商業對象（persistent business objects）提供了一個清楚的模型。在java對象模型中，簡單對象通常都是以一種簡單的方式進行處理但是，很多商業對象所需要的事務化的持久性治理沒有得到實現。entity bean將持久化機制封裝在容器提供的服務里，并且隱藏了所有的復雜性。entity bean答應應用程序操縱他們就像處理一個一般的java對象應用。
　　
　　除了從調用代碼中隱藏持久化的形式和機制外，entity bean還答應EJB容器對對象的持久化進行優化，保證數據存儲具有開放性，靈活性，以及可部署性。
　　在一些基于EJB技術的項目中，廣泛的使用OO技術導致了對entity bean的大量使用，SUN的工程師們已經積累了很多使用entity Bean的經驗，這篇文章就具體闡述的這些卡發經驗：
　　*探索各種優化方法
　　*提供性能優化和提高適用性的法則和建議
　　*討論如何避免一些教訓。
　　
　　法則1：只要可以，盡量使用CMP
　　
　　CMP方式不僅減少了編碼的工作量，而且在Container中以及container產生的數據庫訪問代碼中包括了許多優化的可能。Container可以訪問內存緩沖中的bean,這就答應它可以監視緩沖中的任何變化。這樣的話就在事物沒有提交之前，假如緩存的數據沒有變化就不用寫到數據庫中。就可以避免許多不必要的數據庫寫操作。
　　另外一個優化是在調用find方法的時候。通常情況下find方法需要進行以下數據庫操作：
　　查找數據庫中的紀錄并且獲得主鍵
　　將紀錄數據裝入緩存
　　CMP答應將這兩步操作優化為一步就可以搞定。[具體怎么做我也沒弄明白，原文沒有具體闡述]
　　
　　法則2：寫代碼時盡量保證對BMP和CMP都支持
　　
　　許多情況下，EJB的開發者可能無法控制他們寫的bean怎么樣被部署，以及使用的container是不是支持CMP.
　　一個有效的解決方案是，將商業邏輯的編碼完全和持久化機制分離。再CMP類中實現商業邏輯，然后再編寫一個BMP類，用該類繼續CMP類。這樣的話，所有的商業邏輯都在CMP類中，而持久化機制在BMP中實現。
　　
　　[我覺得這種情況在實際工作中很少碰到，但是作者解決問題的思路值得學習]
　　
　　法則3：把ejbStore中的數據庫訪問減小到最少。
　　
　　假如使用BMP,設置一個緩存數據改變標志dirty非常有用。所有改變數據庫中底層數據的操作，都要設置dirty,而在ejbStore（）中，首先檢測dirty的值，假如dirty的值沒有改變，表明目前數據庫中的數據與緩存的一致，就不必進行數據庫操作了，反之，就要把緩存數據寫入數據庫。
　　
　　法則4：總是將從lookup和find中獲得的引用進行緩存。（cache）
　　
　　引用緩存對session bean和entity bean 都是適用的。
　　通過JNDI lookup獲得EJB資源。比如DataSource,bean的引用等等都要付出相當大的代價。因此應該避免多余的lookup.可以這樣做：
　　l將這些引用定義為實例變量。
　　l從setEntityContext(session Bean使用setSessionContext)方法查找他們。
　　
　　SetEntityContext方法對于一個bean實例只執行一次，所有的相關引用都在這一次中進行查找，這樣查找的代價就不是那么昂貴了。應該避免在其他方法中查找引用。尤其是訪問數據庫的方法：ejbLoad()和ejbStore(),假如在這些頻繁調用的方法中進行DataSource的查找，勢必造成時間的浪費。
　　調用其他entity bean的finder方法也是一種重量級的調用。多次調用finder()方法的代價非常高。假如這種引用不適合放在setEntityContext這樣的初始化時執行的方法中執行，就應該在適當的時候緩存finder的執行結果。只是要注重的是，假如這個引用只對當前的entity有效，你就需要在bean從緩沖池中取出來代表另外一個實體時清除掉這些引用。，這些操作應該在ejbActivate（）中進行。
　　
　　法則5:總是使用PRepare statements
　　
　　這條優化法則適用于所有訪問關系數據庫的操作。
　　數據庫在處理每一個SQL Statement的時候，執行前都要對Statement進行編譯。一些數據庫具有緩存statement和statement的編譯后形式的功能。數據庫可以把新的Statement和緩存中的進行匹配。然而，假如要使用這一優化特性，新的Statement要必須和緩存中的Statement完全匹配。
　　對于Non-prepared Statement,數據和Statement本身作為一個字符串傳遞，這樣由于前后調用的數據不同而不能匹配，就導致無法使用這種優化。
　　而對于prepared Statement,數據和Statement是分開傳遞給數據庫的，這樣Statement就可以和cache中已編譯的Statement進行匹配。Statement就不必每次都進行編譯操作。從而使用該優化屬性。
　　這項技術在一些小型的數據庫訪問中能夠減少Statement將近90%的執行時間。
　　
　　法則6：完全關閉所有的Statement
　　
　　在編寫BMP的數據庫訪問代碼時，記住一定要在數據庫訪問調用之后關閉Statement,因為每個打開的Statement對應于數據庫中的一個打開的游標。
　　
　　法則7：避免死鎖

上一篇：創建靈活易擴展的J2EE企業應用程序框架

下一篇：有狀態會話 bean運行結束時應及時被顯示刪除