EJB weblogic.ejb20.cache.CacheFullException [英] EJB weblogic.ejb20.cache.CacheFullException
问题描述
ejbLoad :: weblogic.ejb20.cache.CacheFullException中的异常： size = 85783，target = 5000，incr = 1在weblogic.ejb20.cache.EntityCache $ SizeTracker.shrinkNext（JI）Lweblogic.ejb20.cache.EntityCache $ MRUElement;（EntityCache.java:438）在weblogic.ejb20.cache。在weblogic.ejb20上的EntityCache.put
（Ljavax.transaction.Transaction; Lweblogic.ejb20.cache.CacheKey; Ljavax.ejb.EntityBean; Lweblogic.ejb20.interfaces.CachingManager;）V（EntityCache.java:141）。 manager.DBManager.getReadyBean（Ljavax.transaction.Transaction; Ljava.lang.Object;）Ljavax.ejb.EntityBean;（DBManager.java:332）at
weblogic.ejb20.manager.DBManager.preInvoke（Lweblogic.ejb20 .internal.InvocationWrapper;）Ljavax.ejb.EnterpriseBean;（DBManager.java:249）at
weblogic.ejb20.internal.BaseEJBLocalObject.preInvoke（Lweblogic.ejb20.internal.InvocationWrapper;）Lweblogic.ejb20.internal.InvocationWrapper ;（BaseEJBLocalObject.java:228 ）在weblogic.ejb20.internal.EntityEJBLocalObject.preInvoke（Lweblogic.ejb20.internal.MethodDescriptor; Lweblogic.security.service.ContextHandler;）Lweblogic.ejb20.internal.InvocationWrapper;（EntityEJBLocalObject.java:72）在com.nextjet.enterprise .locationcode.locationcode.LocationCode_v2epgs_ELOImpl.getLocationCodeData（）Lcom.nextjet.enterprise.locationcode.LocationCodeData;（LocationCode_v2epgs_ELOImpl.java:28）在com.nextjet.enterprise.locationcode.locationcodemanager.LocationCodeManagerBean.loadShippingAddress（Ljava.lang.Long; Ljava。 lang.String;）Lcom.nextjet.enterprise.locationcode.LocationCodeView;（LocationCodeManagerBean.java:538）在com.nextjet.enterprise.locationcode.locationcodemanager.LocationCodeManagerBean.doSearchShippingAddresses（Ljava.lang.String;）Lcom.nextjet.enterprise。 locationcode.LocationCodeSearchResult;（LocationCodeManagerBean.java:514）在com.nextjet.enterprise.locationcode.locationcodemanager.LocationCodeManagerBean.lookupAccountShipping .....
现在我正在更改 weblogic-ejb-jar中的 < max-beans-in-cache> 的值。 xml
我正在将上述值更改为< max-beans-in-cache> 100000< / max -beans-in-cache>
是否是这种异常的唯一解决方案，或者数据库中是否存在与数据有关的问题？
10000对于 max-beans-in-cache 并且从日志中，似乎应用程序试图调用最多85785个EJB实例。
我建议您的代码中重新编写一个。
您的代码正在执行
com.nextjet.enterprise.locationcode.locationcode.LocationCode_v2epgs_ELOImpl
.getLocationCodeData（）
这主要是一个读操作？或者您是否同时进行写入和读取？
如果主要执行读取操作，则可以通过两种方式重构此方法来减少EJB开销
1）阅读Oracle关于调整EJB设置和并发性数据库选项的建议，特别是Read-Mostly模式
http://docs.oracle.com/cd/E13222_01/ wls / docs81 / ejb / entity.html＃ChoosingaConcurrencyStrategy
2）如果你主要是读取 - 那么根本不使用Entity EJB。使用正在使用直接JDBC调用的FastLaneReader模式来获取SELECT的数据，您可以使用目前的EJB进行写入操作。这样，可以减少max-beans-in-cache
在Sun Design Patterns网站上给出了一个非常详细的例子。
http://java.sun.com/blueprints/patterns/FastLaneReader.html
I am working on one application using EJB1.2. previously running fine but from past few days I am getting following exception
Exception in ejbLoad:: weblogic.ejb20.cache.CacheFullException: size=85783, target=5000, incr=1 at weblogic.ejb20.cache.EntityCache$SizeTracker.shrinkNext(JI)Lweblogic.ejb20.cache.EntityCache$MRUElement;(EntityCache.java:438) at weblogic.ejb20.cache.EntityCache.put
(Ljavax.transaction.Transaction;Lweblogic.ejb20.cache.CacheKey;Ljavax.ejb.EntityBean;Lweblogic.ejb20.interfaces.CachingManager;)V(EntityCache.java:141) at weblogic.ejb20.manager.DBManager.getReadyBean(Ljavax.transaction.Transaction;Ljava.lang.Object;)Ljavax.ejb.EntityBean;(DBManager.java:332) at
weblogic.ejb20.manager.DBManager.preInvoke(Lweblogic.ejb20.internal.InvocationWrapper;)Ljavax.ejb.EnterpriseBean;(DBManager.java:249) at
weblogic.ejb20.internal.BaseEJBLocalObject.preInvoke(Lweblogic.ejb20.internal.InvocationWrapper;)Lweblogic.ejb20.internal.InvocationWrapper;(BaseEJBLocalObject.java:228) at weblogic.ejb20.internal.EntityEJBLocalObject.preInvoke(Lweblogic.ejb20.internal.MethodDescriptor;Lweblogic.security.service.ContextHandler;)Lweblogic.ejb20.internal.InvocationWrapper;(EntityEJBLocalObject.java:72) at com.nextjet.enterprise.locationcode.locationcode.LocationCode_v2epgs_ELOImpl.getLocationCodeData()Lcom.nextjet.enterprise.locationcode.LocationCodeData;(LocationCode_v2epgs_ELOImpl.java:28) at com.nextjet.enterprise.locationcode.locationcodemanager.LocationCodeManagerBean.loadShippingAddress(Ljava.lang.Long;Ljava.lang.String;)Lcom.nextjet.enterprise.locationcode.LocationCodeView;(LocationCodeManagerBean.java:538) at com.nextjet.enterprise.locationcode.locationcodemanager.LocationCodeManagerBean.doSearchShippingAddresses(Ljava.lang.String;)Lcom.nextjet.enterprise.locationcode.LocationCodeSearchResult;(LocationCodeManagerBean.java:514) at com.nextjet.enterprise.locationcode.locationcodemanager.LocationCodeManagerBean.lookupAccountShipping.....
For now I am changing value of <max-beans-in-cache> in weblogic-ejb-jar.xml
I am changing the above value to <max-beans-in-cache>100000</max-beans-in-cache>
is it the only solution for this kind of exception or could there be a data related issue from database?
10000 is quite a high value for max-beans-in-cache and from the log it seems the application tried to make a call for up to 85785 instances of the EJB.
I would suggest some refactoring in your code.
Your code is doing
com.nextjet.enterprise.locationcode.locationcode.LocationCode_v2epgs_ELOImpl
.getLocationCodeData()
Is this is mainly a read operation ? Or are you doing simultaneous writes and reads?
You could refactor this in 2 ways to reduce the EJB overheads if it is mainly doing read operations.
1) Read Oracle's recommendation on tuning the EJB settings and database options for concurrency, especially the Read-Mostly pattern
http://docs.oracle.com/cd/E13222_01/wls/docs81/ejb/entity.html#ChoosingaConcurrencyStrategy
2) If you are mainly doing reads - then dont use Entity EJBs at all. Use the FastLaneReader pattern which is using a direct JDBC call to fetch the data for SELECT, and you can do writes using the EJBs as at present. In this way, the max-beans-in-cache can be reduced
A very detailed example is given on the Sun Design Patterns site
http://java.sun.com/blueprints/patterns/FastLaneReader.html
这篇关于EJB weblogic.ejb20.cache.CacheFullException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
