Great fucking idea! I shoulda thought of that. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Michael Bartmann > Sent: Wednesday, September 11, 2002 4:07 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Deadlock retry interceptor > > > Hi deadlock lovers, > > I just did a deadlock-retry-interceptor, which was more easy than > I thought. > There is a serverside variant and a client interceptor. >
I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. > The interesting (i.e. non-perfect) points are: > > - how to configure retry strategy (quite simple now) > - where to place the serverside thing in the chain (should be _outside_ > of the transaction which just rolled back due to the deadlock; this > probably implies that it could have to be done inside the TxInterceptor > when entering a new tx. > When _not_ doing "RequiresNew" the interceptor works fine between the > SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. > - what to do with MDB (they are supposed to catch everything, so nothing > gets through to the interceptor. My best guess is to use a > UserTX inside > the MDB, do the retry "manually" (w/o interceptor) and put all this in > an AbstractDeadlockRetryMDB (I did this, it worked fine). > Can't you put it in the TxInterceptor for MDB? > Is there any interest to put this into Branch_3_2? > Send it to me. I'll get it in. Its definately worth it. Bill ------------------------------------------------------- In remembrance www.osdn.com/911/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
