可能的問題
通常，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就不必每次都進行編譯操作。從而使用該最佳化屬性。