I'm pretty sure the original intent of this code was to lock on any method invocation if the bean already belongs to a different transaction. Also, take a look at EntitySynchronizationInterceptor. It will call storeEntity if the method does not belong to a transaction. Since JBoss does not have a bean instance per invocation(or rather per transaction), updates being executed within a non-committed transaction will be committed. This would be bad bad bad. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Stuart Hill > Sent: Tuesday, June 19, 2001 11:11 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] EntityInstanceInterceptor blocking when there is no > transaction > > > Hello JBoss gurus > > I've spotted what might be small problem in > EntityInstanceInterceptor.invoke(MethodInvocation mi). > > What if mi.getTransaction() returns null because you are, for instance, > invoking a "NotSupported" method? Is it still appropriate to block in this > case? > > The code in question is near the beginning of the while (!mutex.isValid()) > loop. > ... > // Do we have a running transaction with the context > Transaction tx = ctx.getTransaction(); > if (tx != null && > // And are we trying to enter with another transaction > !tx.equals(mi.getTransaction())) > { > // Let's put the thread to sleep a lock release will wake the thread > // Possible deadlock... > > > Cheers > > Stuart Hill > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
