Re: Strange deadlock with object/target of lock : transaction

On 25/8/25 17:58, Adrian Klaver wrote:
> On 8/25/25 07:40, Achilleas Mantzios wrote:
>> On 8/20/25 14:59, Achilleas Mantzios wrote:
>>
>>> On 8/14/25 16:01, Achilleas Mantzios wrote:
>>>
>>>> Hi Adrian
>>>>
>>>> On 8/14/25 15:39, Adrian Klaver wrote:
>>>>
>>>>> On 8/14/25 00:07, Achilleas Mantzios wrote:
>>>>>> Hi All
>>>>>>
>>>>>> We've been hit by a weird deadlock which it took me some days to 
>>>>>> isolate and replicate. It does not have to do with order of 
>>>>>> updates or any explicit TABLE-level locking, the objects/targets 
>>>>>> of the deadlock in question are transactions.
>>>>>
>>>> First off, I maybe wrong with the above conclusion, I noticed that 
>
>> Hi I reproduced without the triggers, I understood the problem, I 
>> believe the system's behavior is the intended, I am sorry for the 
>> false alarm. The thing is that it takes >=3 transactions to happen . 
>> That was the tricky part, up to now in all cases of deadlocks we had 
>> two transactions involved, this one needed three or more.
>
> For folks that run across this thread what was the issue?
Inconsistent order of updates. The two pieces of code , the update piece 
and the insert piece, used inconsistent order of updates. However this 
could not be manifested with one xaction of the update-type and one of 
the insert-type, there had to be more than one transactions of the 
update-type doing the same update (usually caused by users hitting the 
reload button after 1 or 2 seconds). I can easily prepare a test case, 
schema, data, commands for anyone interested.