Hi,
Just had a quick look at this, and you are
absolutely right.
Exceptions from beforeCompletion methods should
be caught and result in a rollback.
Exceptions from afterCompletion should be caught
and ignored (too late to rollback).
And the XAResource calls have similar problems.
I'm currently testing some other changes to
package org.jboss.tm.
I'll fix this too, and expect to commit in a day
or two.
Best Regards,
Ole Husgaard.
danch wrote:
>
> With tonight's CVS as well as 2.0 FINAL, if an ejbLoad method throws an
> EJBException (or any runtime exception), JBoss fails to rollback the
> transaction and discard the bean instance per spec. (section 12.3 of the
> 1.1 spec).
>
> This might be a fairly nasty issue: my initial symptom was having later
> requests for the same bean doing the 'LOCKING-WAITING' thing in
> EntityInstanceInterceptor, which indicates that the transaction stuff
> never let go of the bad bean, either.
>
> Looking into TxCapsule, it looks to me like if an exception is thrown
> out of doBeforeCompletion (like this), endResources, afterCompletion,
> etc. never get called. Since afterCompletion (on the
> InstanceSynchronization inner class in EntitySynchronizationInterceptor)
> seems to be where the instance gets disassociated from the transaction.
>
> I'm thinking that TxCapsule needs to be beefed up WRT exception
> handling, which could accomplish the rollback. That should also arrange
> for the instance that's at fault to not go back into the pool in
> afterCommit, but I'm not sure how that would be accomplished.
>
> g'd night!
> danch
