由于有多個事務同時運行在一個容器上很正常，所以可以想象如果上面的代碼被從一個會話或MDB bean中調用，其中該bean是利用一個較高的max-beans-in-free-pool參數值(默認1000)部署的，并且同時有50個客戶端請求。這使得每個事務在實體緩存中只有1000/50 = 20個可用的槽，如果一個finder返回的對象超過20個，有的事務就會失敗。
在設計具有大量實體bean的操作時要時刻牢記這一點。開發人員通常使用小型數據庫這一事實使情況變得更糟，并且該問題可能并不表現出來，直到代碼部署到生產規模的數據庫中時。作為保護措施，我建議在開發過程中不要使用默認的緩存大小，而是將其較低值(10-100)，這樣緩存相關的問題就能在開發早期發現并解決。
如您所見，為實體緩存選擇正確的大小非常重要，并且不只是從性能的角度來看。如果緩存過大，您的應用程序將消耗很多不必要的內存，但是如果您走到另一個極端，配置過小的緩存空間，會有收到CacheFullException的風險。那么該如何為所有的實體bean選擇最佳的緩存大小呢?
如果您沒有明確為實體bean指定緩存大小，WebLogic Server將使用默認大小1000。這對于預先知道實例數不會太多的某些bean來說足夠了——比如，如果一個bean表示數據庫中的一個查詢表，比如“country”或“state”，其中bean實例的上限是已知的。這種情況下，不指定緩存大小而讓服務器使用默認值是完全可接受的，因為如果緩存沒有被充分利用不會對內存造成影響。順便指出，為不變化或不頻繁變化的bean使用只讀并發策略是一個不錯的注意;這不但消除了不必要的數據庫調用，還限制了與該bean的實體緩存中的實例具有同樣PK的實例數(多版本是不是必要的),從而節省了內存，提高了性能。
對于其中可同時訪問的最大實例數未知或不能可靠地估計出來的bean，情況略微復雜些。您需要分析和估計從finder方法返回以及從一個事務內訪問的最大bean數，然后乘以可同時發生的最大事務數(這通常受您應用程序入口點的最大實例數限制——會話bean和/或MDB)。這能粗略地估計出特定實體bean所需的最小緩存容量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
