marc fleury wrote:
>
> > BTW: Is the org.jboss.tm.TxCapcule class supposed
> > to be thread-safe?
>
> It assumes one thread of control, (the way it is used now in the container)
> but synchronizing it might be a good idea,
I have looked further into this code and found quite a few TODOs.
I've done these:
- Made TxCapsule thread-safe. I used a mutex instead of the native
synchronization construct to avoid deadlock when outgoing calls
loop back (ie. xaResource.prepare() resulting in setRollbackOnly()
being called).
- Made various TxCapsule throw the exceptions they should according
to the JTA spec. (That included declaring a few more throw clauses
to signatures in TxManager and TransactionImpl.)
These are still on the TODO list for TxCapsule:
- Proper handling of heuristic decisions, and throwing heuristic
exceptions.
- Implementation of timeouts.
- Implement saving of commit decision to stable storage and recovery
after server crash. This is a big job and can significantly slow
down commit. Should probably be an option.
Now I am testing calling setRollbackOnly() from a BMP business method.
But this results in a EJBException thrown from
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.register().
What happens is that EntitySynchronizationInterceptor.invoke() tries
to register a transaction synchronization _after_ invocation, but
by then the transaction has already been marked for rollback in the
BMP bean, and the JTS specification and J2EE javadocs clearly state
that in this case tx.registerSynchronization() should throw a
RollbackException. EntitySynchronizationInterceptor.register() then
wraps the RollbackException in an EJBException and throws the
EJBException.
I don't know the EntitySynchronizationInterceptor code at all, so
I'm not sure what is the right thing to do here.
Best Regards,
Ole Husgaard.
