ludovic orban wrote:
>> > This has absolutely nothing to do
>> > with XA nor interleaved transactions and you could reproduce the exact
>> > same behavior with two different connections.
>>
>> I challenge you to do so. ;)
>
> Done. See attached test case.
Ahh, I see what you mean now.
Technically, with your modified test case, what you get is not a
*deadlock*, it's a serialization error. Which is different: the deadlock
in my original test case doesn't get resolved until a timeout kicks in,
whereas in your modified test case the serialization error is detected
as soon as A commits.
Actually, I'm surprised that Firebird notices the deadlock in my
original test case at all.
You can "fix" the test case by changing the commit call in the Committer
thread to a rollback. What should then happen is that the second update
continues as soon as A rolls back. There's no conflict because A
rolled back, right?. With that modification, your test case runs OK, and
mine throws the same exception as before.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
