> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Thursday, July 19, 2001 6:21 AM > To: [EMAIL PROTECTED]; Jboss-User@Lists. > Sourceforge. Net > Subject: RE: [JBoss-dev] WARNING: No rollback on transaction timeout > with mainline(2.5) > > > hmmmmmmmmmmm > > a transaction timeout is an operation limited to the Tx manager, meaning > that there is no "callback" afaik. > > If a tx times out, the thread associated with it should still come back > through the interceptor and carry a "timed-out" transaction. > > What I am saying is that a thread that doesn't return is a > problem in and on > itself that the transaction associated with it times out is not going to > change that. > Yeah, but the classic deadlock scenario is not JBoss's fault, but the fault of the Bean Developer. This is one of the reasons why the LOCKING-WAITING message is so useful. If a transaction times out you can search the logs for LOCKING-WAITING to find out if it was a deadlock scenario introduced by your bad coding.(Hey, it's helped out debugging my aweful app code many a time :) Just to make sure we're on the same page here, I tested classic application deadlock with wait() and the 2 transactions never timed out. This is because the Tx manager does nothing but mark the transaction as ROLLBACK. So with wait() + classic deadlock, threads will wait forever and never know that they have been rolled back. I put in a wait(timeout) instead, and the transactions did timeout. Maybe this is what you were saying and you already agree, but, I couldn't tell. > The other threads waiting will be notified through normal mechanisms when > the thread taking all this big time will return. If the thread doesn't > return (as from JBossMQ for example) then that is a bug. > Just to make sure again, it could be an application bug and not a JBoss bug if you're using wait() with no timeout. > You see I am very happy we can see that JBossMQ hangs, right > there, because > of the wait(). > I totally understand the usefulness of having wait() in there for testing out the new cache/locking mechanisms. I just wanted to make sure that the JBoss community knew possible problems with using it. Bill > The wait(5000), as we all agree, is the way to go for the final > system. But > a time-out with a returning thread will notifyAll. > > marcf > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Monday, July 16, 2001 8:12 PM > To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. > Sourceforge. Net > Subject: [JBoss-dev] WARNING: No rollback on transaction timeout with > mainline(2.5) > > > FYI, > > For debugging purposes in JBoss 2.5(mainline), threads waiting on > EntityBeans will not be rollbacked on transaction timeouts and will wait > forever. Currently the codebase does a wait forever, wait(), on > transaction > and method lock objects. This was done on purpose to easily > catch problems > with the new locking code put into 2.5. To fix this problem edit > org.jboss.ejb.plugins.EntityInstanceInterceptor and comment out any line > that does a wait(), and uncomment out lines that do wait(timeout). > > Regards, > > Bill > > > _______________________________________________ > 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
