Reentrant method call exceptions in JBoss 3.0.3 and 3.0.4

[juang]

Hi all,

We had ported our web apps from weblogic to jboss, and now we are in the process of certifying the port for production. As part of this process we are trying to define which version of Jboss we should be using.

We decided to use 3.0.3, but when we run stress tests on our applications, we are finding reentrant method call exceptions. We tried the same thing on 3.0.1 and 3.0.2 and these exceptions are not happening. We reviewed the code in our web apps to detect any reentrant method call, but we couldn't find any.

Obviously there has been a change in the way Jboss checks for reentrant method calls after 3.0.2, so my question is if this because of a more strict implementation of the J2EE specs?

Thanks,

Juan Gargiulo

[juha]

From 3.0.3 changelog:


module: src/main/org/jboss/ejb; files: BeanLock.java, BeanLockManager.java

module: src/main/org/jboss/ejb/plugins/lock; files: BeanLockSupport.java, MethodOnlyEJBLock.java

module: src/etc/conf/default; files: standardjboss.xml
QueuedPessimisticEJBLock.java,

module: src/main/org/jboss/ejb/plugins/lock; files: NoLock.java

comments Removed method locking. It is now replaced with EntityReentranceInterceptor
lock, just check reentrancy. If reentrant throw exception as per the spec.
Added EntityReentrancyInterceptor and replace MethodOnlyEJBLock in Instance Per Transaction
with NoLock to standardjboss.xml.


module: src/main/org/jboss/ejb/plugins; files: EntityReentranceInterceptor.java

comments Replaces method locking. If instance is reentered, throw exception, as per the spec.

[okidoky]

Reentrant checked is nice and everything, but in 3.0.4 (and 3.0.3 presumably) it also doesn't like it when you're accessing an entity beans from 2 threads at the same time.

In my opinion any non transacted entity beans are broken if your accessing your entity beans from more than one thread (eg, a website with multiple people logged in).

[sieroka]

Anything that can be done as a work around? We have a distributes application that has multiple clients, and we get this exception in the same way (More than one thread accessing the entity bean). If we allow reentrant calls we get some sort of out of connections error. I thought the spec described reentrancy as an entity bean calling another entity bean which calls the first entity bean again. This seems to have nothing to do with two threads...

[timfox]

You could try using the "Instance Per Transaction" container consideration - in this config - each transaction gets its own instance of the entity hence no possibility of deadlock etc., also mark your beans as re-entrant.
(Containers find it difficult to differentiate a "truly reantrant" call (ie one in same transaction) from just another thread calling the same bean concurrently - hence the concept of "marking beans as reentrant"))
JBoss standard config. is shared instance, so lots of probs with deadlocks, and not very scaleable (IMO).
For good scaleabilty in enterprise apps, that are read mostly IMO use instance per transaction config., and add optimistic locking on top.
For more info there's a whole section on this in the jboss paid docs.

[bclyonlx]

JBossers -

Did anyone ever get a solution to this problem?

I am using JBoss 3.0.3 with the Hypersonic database. I have a very simple CMP 2.0 entity bean which is definitely not re-entrant (it has no references to any beans in its methods). It is non-transactional.
If I create 1000 instances of this bean I can no longer access them; I always get the 'javax.ejb.EJBException: Reentrant method call detected'
This never happens if there are only dozens of instances at a time, even if I create and destroy thousands of of instances over a period of some minutes.
With 1000 instances, even if I restart JBoss and try to list the instances with a servlet (only one single-threaded client), I get the same error.
Other beans on the same server with fewer instances do not have any problems.

This is an extremely serious problem for my application; I don't understand why the system cannot handle increasing the number of instances of the bean to such a (relatively) modest number.

Bruce Lyon