WebLogic Server中CMP實體bean的性能調優[8] 軟件測試
WebLogic Server 9.0中的改進
在WebLogic Server 9.0中，對使用樂觀并發的緩存bean進行的顯式緩存禁用被歸檔，并且與只讀bean一致。(比如，bean home或遠程主接口可被緩存到上面調用的CachingHome或CachingLocalHome和invalidate()方法中)。此外，read-timeout-seconds參數適用于用樂觀并發部署的bean。開發人員還對集群中的bean實例無效化有更多的控制。默認情況下，當在一個集群中部署具有樂觀并發策略的bean，并且該集群的一個成員更新該bean時，WebLogic Server會試圖使該集群的所有節點中的bean的所有副本無效。該無效化使您避免了樂觀并發故障，但是會影響性能，因為它是一項資源密集型操作�？赏ㄟ^在weblogic-cmp-jar.xml中將cluster-invalidation-disabled設置為true來防止EJB容器使集群中的bean副本無效。
為實體Bean選擇最佳緩存大小
既然您理解了事務間的緩存是如何工作的，下面就讓我們討論一下選擇最佳緩存大小方面的重要話題。默認情況下，每個實體bean都定義有一個大小為1000的緩存。緩存大小由weblogic-ejb-jar.xml部署描述符中的max-beans-in-cache元素控制。我發現該名稱有些令人誤解，因為根據并發策略的不同，WebLogic Server保存無狀態的實體bean實例池(采用數據庫并發策略和排他性并發策略，且事務間緩存被禁止的情況下)或者(只讀、樂觀或排他性并發策略，且事務間緩存啟用的情況下)保存具有保留字段值的bean的真正緩存，從而無需從數據庫中重新加載bean的狀態就可使用。后一種情況更有趣。有人可能會想，更改緩存大小只影響具有實體bean的操作的性能;緩存越大，在緩存中發現需要的特定實體bean實例的機會就越大�；旧鲜沁@樣的，但是如我下面會講到的那樣，另一個重要因素會影響緩存大小的選擇。
多版本化和事務的因素
確定實體bean緩存大小的推動因素之一(可能不太明顯)是當事務使用實體bean時，它們在事務的執行期間被實際加載和“固定”在實體緩存中，即使調用者不在修改實體bean實例而僅是從中讀取值。比如，想象一下，一個會話或MDB bean中的代碼在一個實體bean “Person”上執行一個finder方法，然后在返回的集合上迭代。
...
Collection persons = personLocalHome.findSomething();
for (Iterator iter = persons.iterator(); iter.hasNext();) {
PersonLocal person = (PersonLocal)iter.next();
Long id = person.getId();
// do something: log, send email, etc
...
}
...
如果findSomething()方法返回比max-beans-in-cache中規定的值更多的對象，您的應用程序將在迭代器得到N+1個對象時(N為當前實體緩存大小)獲得一個令人不愉快的(并且很可能是不想要的)CacheFullException。這可能看上去很重要，因為一般大家都認為finder不應返回很大的集合。但是不要忘記默認情況下WebLogic實體緩存是多版本的，這意味著如果多個事務請求同一個實體bean實例，那么會在緩存中創建多個版本(每個事務一個);從唯一對象的角度來看這可能極大地降低了緩存容量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/