優化Entity Bean的七條準則
發表于:2008-08-07來源:作者:點擊數:
標簽:
entitybean為在應用程序和設計中描述持久化商業對象(persistentbusinessobjects)提供了一個清晰的模型。在 java 對象模型中,簡單對象通常都是以一種簡單的方式進行處理.但是,很多商業對象所需要的事務化的持久性管理沒有得到實現。entitybean將持久化機制
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.可以這樣做:
??☆ 將這些引用定義為實例變量。
??☆ 從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:避免死鎖
??關于作者:
??Akara Sucharitakul:Sun公司內部包括Ecperf benchmark在內的多個J2EE
服務器端應用的開發者之一。他有至少5年使用java技術的開發經驗,并且從J2EE技術的初期就一直從事此方面的開發工作。
原文轉自:http://www.anti-gravitydesign.com