Hi,
marc fleury wrote:
> Ok the f*cked up thing was that the tx was then propagated with
> Tx-marked-rollback and for some "JTA" exception Ole had added a nice check
> that basically disables the registration of the synchronization callback to
> the infrastructure, so that in a very screwed up way the container never was
> notified of the transaction demarcation.... Ole... that decision to not
> notify the container on transaction demarcation is a serious one... I will
> say "mybad" in the fact that I did not catch something like that before, but
> transaction demarcation is deep in the container and disabling it for
> "warning" is dangerous.
You are talking about Transaction.registerSynchronization()
throwing a RollbackException if the transaction is marked
rollback only?
Personally I do not like it, as I think it makes no sense.
After all, we might still want afterCompletion called
after the rollback has happened.
On my first reading of the JTA specification I thought that
it was quite explicit and consistent about this: RollbackException
_must_ be thrown in this case.
For comparison, CORBA OTS takes a more sensible stand on
this: The RollbackException _may_ be thrown in this case.
J2EE RI _always_ throws a RollbackException in this case.
But after having another look on the JTA specification and
the JTA javadoc, I am not so sure any more. It seems that
it is the same sentence that has been cut-n-pasted:
"RollbackException: Thrown to indicate that the transaction
has been marked for rollback only."
Please note that is does not explicitly say that this
exception _must_ be thrown.
So with maybe after all it is not a JTA violation not
always throwing this exception in this case (even if
the RI always does)?
But even with the best intentions, I find it impossible
to read JTA as saying this exception will _never_ happen
in this case. After all the exception is declared and
documented.
So it may be dangerous to program as if
Transaction.registerSynchronization() will _never_ throw
this exception. Even if we make out own JTA implementation
never throw this exception in this case (which is quite
simple), things may break if/when someone tries to use
another JTA implementation.
> Again I know you notified us (afaik), so I guess it
> is OK, :)
It may be OK, but it is still bad...
> BUT GUYS that one was nasty to catch since it was 2 bugs on top of one... ok
> we have a "fix" which basically is to remove the Ole "check" but it remains
> Aaron that I don't think Minerva should rollback transactions in his corner,
> that decision is up to the application or container. At any rate it will
> show that being bearer of bad news usually means bad news for one-self ;-).
While I do not know if the TX rollback in Minerva is right
or wrong, it should not be a problem.
Why? Because asynchronous transaction rollbacks happen, and
there is very little we can do about it when we interoperate
with other transaction managers.
JTA throws RollbackException and IllegalStateException all
over the place mostly because of this. It should be simple
for a JTA user to just check getStatus() to avoid getting
one of these exceptions, but it is not because of the
asynchronous rollback.
I did this in the transaction timeout, and this has now been
changed to just marking for rollback only.
Even if we interoperate with a transaction manager that has
checked transaction behaviour, this TM may rollback while
calls are active in jBoss. This TM and the code that starts
and terminates transactions may be completely outside our
control. If we try to play games like always interposing and
delaying rollback requests until all invocations in the TX
are done, the delay introduced by this will make jBoss look
faulty and be generally unacceptable for most people who want
to do distributed transactions in large systems.
> Let me know what you guys see there in both cases as we need to do it
> right...
So done.
Making TX timeout only mark the TX for rollback only, and
making registerSynchronization() never throw RollbackException
may be a good thing to do now we are so close to the deadline.
But I consider these only fixes for the symptoms of a larger
problem: jBoss has problems with asynchronous TX rollbacks.
Best Regards,
Ole Husgaard.
