Aaron Mulder wrote:
>
> Okay, I fixed the problem with TxCapsule that was preventing
> commits from going through. But I'm not totally sure what the intent was,
> so I'm not sure I fixed it right. Either the != was supposed to be an ==,
> or you meant to set the status field somewhere else.
It was meant to be ==, blame on me for not properly testing a last-minute
edit.
This check is for when the timeout kicks in, in which case the status should
change to STATUS_MARKED_ROLLBACK, and we should get a mixed heuristic
exception. But this doesn't seem to work either.
> Speaking of the status field, in the commitResource method, it
> doesn't seem like the status field gets changed if there's an XAException,
> so everything would still proceed A-OK if there was an exception, which I
> think is bad.
For heuristic exceptions I just invoke gotHeuristic() to note that a heuristic
exception should be thrown, and continue.
For other XA exceptions I just log the exception and continue as if nothing
happened (which is probably wrong).
> Also, if there's a heuristic commit or rollback exception,
> the commitResource calls gotHeuristic which calls forget, but then the
> original commit calls rollback if the commitResource didn't succeed, and
> you can't call rollback after forget!
You mean that I _can_ rollback a XA resource that gave me a heuristic
exception if I just don't do forget() on it first?
If so, that would help a lot.
But wouldn't it give some problems with transaction isolation?
> Overall, I think this TxCapsule work needs more thought and
> testing before we release a binary - a simple test with Minerva and a DB
> that supports transactions would have revealed the original bug I fixed,
> which meant every commit failed!
Sorry again. I've done most of the testing with the Minerva XA pool,
just not the last minute changes.
I'll do a patch for the tx timeout problem in STATUS_COMMITTING state.
Best Regards,
Ole Husgaard.
