JBossDeveloper

Hey Guys,

We're getting the same issue under heavy load. Anyone have solution, suggestions or ideas? We're running JBoss 3.2.1.


Thanks,

Shaun

Hey All,

has anyone of you ever overcome this error? Is it fixed in the latest JBoss version? Unfortunately we're still using 3.2.1 and haven't found a workaround for it yet.

Thanks,
Stefan

Hi Smeier

I've tried out 3.2.7, and haven't seem the problem reoccur since then. So while I can't say for sure whether or not it was fixed, it certainly seems that way.

HTH
Collin

Hi All,
Is it fixed in the latest JBoss version?
I have the same problem with JBoss-3.2.1.

Even if a version upgrade always requires some work I would strongly recommend an upgrade to a JBoss version > 3.2.6 as there is a connection pool leak in earlier JBoss versions under heavy load.

Regards
Ulf

Thanks Ulf.
I will upgrade to JBoss 3.2.7

I have same problem on JBoss 4.0.2 under heavy load!!!
JDK is 1.5.0_4 for Linux

Is there any plans to fix it???

2005-08-02 22:59:48,498 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException in method: public abstract java.util.List com.adigida.ejb.session.CompanyManagementLocal.getUsersOffices(java.lang.Long) throws javax.ejb.FinderException, causedBy:
javax.ejb.EJBException: CMR field value is already loaded
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge$FieldState.loadRelations(JDBCCMRFieldBridge.java:1979)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.load(JDBCCMRFieldBridge.java:1417)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.load(JDBCCMRFieldBridge.java:1404)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.getInstanceValue(JDBCCMRFieldBridge.java:717)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.getValue(JDBCCMRFieldBridge.java:669)
 at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:133)
 at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:91)
 at org.jboss.proxy.compiler.Runtime.invoke(Runtime.java:62)

Hi,

Same problem under JBOSS 4.0.2. We get this while stress testing our application. We use a JSP to render 1-N entity beans.

javax.ejb.EJBException: CMR field value is already loaded
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge$FieldState.loadRelations(JDBCCMRFieldBridge.java:1979)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.load(JDBCCMRFieldBridge.java:1417)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.load(JDBCCMRFieldBridge.java:1404)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.getInstanceValue(JDBCCMRFieldBridge.java:717)
 at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.getValue(JDBCCMRFieldBridge.java:669)
 at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:133)
 at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:91)
 at org.jboss.proxy.compiler.Runtime.invoke(Runtime.java:62)

We found the solution for our project. Because of the (old) architecture of our project, we are forced to use a non-standard configuration. That is, we use Standard CMP 2.x EntityBean with cache invalidation for our Entity Beans, with commit option A _and_ Optimistic Locking.

The Wiki article http://wiki.jboss.org/wiki/Wiki.jsp?page=CMPCaching clearly states that when we want global caching we must use Pessimistic Locking (which is default btw.) The problem we had with Pessimistic Locking is that it produced a lot of "Application deadlock" errors so instead we opted for Optimistic Locking which gave us "CMR field value is already loaded".

Our Session Beans use "Supports" by default for transaction type and "Required" only for methods which need to write to the database. Our Entity Beans were completely "Required". Since there was no need for the getter methods to be "Required", we made them read-only and "Supports" to make sure they don't start a new tx.

We use Xdoclet:

 * @ejb.transaction
 * type="Supports"
 * @jboss.method-attributes
 * read-only="true"