Undetectable ApplicationDeadlockExceptions
I have a stateful session bean that will deadlock relatively easily. I'd like very much for my client to be able to detect deadlock situations and restart offending transactions. However, ApplicationDeadlockExceptions aren't propogated to the client.
My beans use CMT; org.jboss.ejb.plugins.TxInterceptorCMT successfully detects any deadlocks, throws an ApplicationDeadlockException, and re-tries the transaction. Unfortunately, org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor is higher in the interceptor stack, and has already caught the ApplicationDeadlockException, and, as it is a subclass of java.rmi.RemoteException, has discarded the offending session bean instance. Thus when TxInterceptorCMT re-tries the transaction, the offending session bean instance is no longer available, and a java.rmi.NoSuchObjectException is thrown and propagated to the client.
The result is my client gets a NoSuchObjectException (with no chained exceptions) and has no way of determining whether this was due to a deadlock (in which case it can automatically create a new session bean instance, and re-try the transaction) or some other exceptional error.
Is there any way to prevent TxInterceptorCMT from re-trying transactions that have deadlocked, without customising TxInterceptorCMT (or writing a customer TX interceptor), and other than setting TxInterceptorCMT.MAX_RETRIES from custom Java code? Should I use BMT instead? My preferred solution would be to "save" a stateful session bean instance from being discarded when a deadlock is detected by JBoss, but as long as ApplicationDeadlockException extends java.rmi.RemoteException, I assume this is not possible.
I'm using JBoss 3.2.3. Any help will be much appreciated.
My apologies for possibly posting this in the wrong forum; it's been in the EJB user forum (with subject "ApplicationDeadlockException, retries and stateful session beans") for over a month, with 33 page views and zero replies or leads. It does seem to be a bug/flaw that TxInterceptor prevents client code from detecting the ApplicationDeadlockException by re-trying the transaction and thus triggering the NoSuchObjectException, without any deployment options for customising this (other than linking directly against JBoss code and modifying TxInterceptorCMT.MAX_RETRIES).
Cheers,
Damian
