|You are talking about Transaction.registerSynchronization()
|throwing a RollbackException if the transaction is marked
|rollback only?
yes that is one and also the fact that you had added a "check" somewhere to
fix the JTA warning that essentially threw us off...
|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.
yes, that is a solution
|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.
well that is the other solution, the container will take a decision based on
it.
Either way I want to know, either through the callback, either through the
exception that I should free the context. As it was neither was true.
|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.
Yes, I understand. Again either way is fine, but let there be one :)))
|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)?
Ok again I am not saying one or the other is right or wrong. I am saying
the container should be notified somehow...
|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...
don't worry about it. It works.
|> 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.
it is not right or wrong, what was wrong was enable the extra check (now
under SA FIXME I believe)
|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.
sure, again as long as the container has a way either actively (call a
method) or passively ( a callback or an exception) then I have a way to do
the proper thing in the container which is ok... Again that part is ok right
now (with the "check" removed :)
|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.
you lost me there, if the tx is rollback ALL I want is to be notified.
Real-time (with an exception) is ok.
|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.
I don't see that... if you let the manager either callback or throw an
exception then I will be notified that another thread has touched the tx...
bear in mind that we don't make assumptions about single thread ( ;-) of
control in the TX. All we need is the proper notification.
I need to accept the "registration" of a synchronization on a "marked for
rollback transaction". If you want to throw an exception right away, we are
ok with that, if you want to allow registration and allow the "commit" to go
to a "afterCompletion(false)" which it does now with the fixed CVS, that is
fine as well. But maybe I miss your point.
regards
marc
|
|
|Best Regards,
|
|Ole Husgaard.
|
|
