java學習心得筆記

　　可能的問題

　　通常，ejb組件在容器之間的移植不可避免地與如下問題相關：

　　1.它需要依靠的受限制的特點在特定ejb容器中沒有得到加強。

　　2.它需要依靠的非標準的服務從容器中可獲得。

　　為了保證ejb組件的可移植性和一致的行為，你應該使用一個具有與java2平臺安全

　　策略集相一致的策略集的容器來測試ejb組件，并且其加強了前述的編程限制。

　　總結

　　ejb組件開發者應該知道這些推薦的關于ejb組件的編程限制，明白它們的重要性，并且從組件的穩定性和可移植性利益方面考慮來遵循它們。因為這些編程限制能阻止你使用標準的java語言的特點，違背了這些編程限制在編譯時不會知道，并且加強這些限制也不是ejb容器的責任。所有這些原因都使你應很小心地遵守這些編程限制，這些限制在組件的合同中已經成為了一個條款，并且它們對于建造可靠的、可移植的組件是非常重要的。

　　2. 優化ejb

　　entity bean為在應用程序和設計中描述持久化商業對象（persistent business objec ts）提供了一個清晰的模型。在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就不必每次都進行編譯操作。從而使用該優化屬性。