Hi,
Might as well mention my next problem, as this is also in
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.
If I violate JTA by allowing registering synchronizations
on a transaction marked for rollback, I get around the first
problem.
But on the next call to my bean entityContext.getPrimaryKey()
returns null. (Yes, I still have my context, unsetEntityContext()
was not called.)
The problem this time is the rollback cleanup in afterCompletion()
in EntitySynchronizationInterceptor. This wasn't called previously,
but now I call the synchronization afterCompletion() functions
after the rollback is complete, like the JTA specification says
I should.
The following code snippet from EntitySynchronizationInterceptor
.InstanceSynchronization.afterCompletion() should give a hint as
to where this problem might be:
ctx.setId(null);
ctx.setTransaction(null);
container.getInstanceCache().remove(ctx.getId());
Best Regards,
Ole Husgaard.
Ole Husgaard wrote:
>
> 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
^ I meant JTA, of course.
> 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.
