RE: Question about locks and deadlocking

I think you slapped a TABLE_B in there when you meant the same TABLE_A. Otherwise the answer is the trivial there is no conflict.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Matt McPeak Sent: Thursday, July 08, 2021 3:18 PM
To: Oracle List
Subject: Question about locks and deadlocking  

Oracle experts,  

I (think) I understand how application design problems can lead to deadlocks. E.g.,  

USER1: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID = 100; USER2: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID = 101; USER2: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID = 100; (waits for user1)

USER1: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID = 101; (deadlocks)  

To avoid this, user1 and user2 should have done their updates in the same order.  

Something I never thought about before is this scenario:  

USER1: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID BETWEEN 100 AND 200; USER2: UPDATE TABLE_B SET COLUMN_A = 'X' WHERE ID BETWEEN 100 AND 200 AND EXISTS (... something else that throws off execution plan maybe);  

I thought I understood that, as each transaction processes rows, it adds itself to the ITL of every block it touches and flags each row as locked by that ITL entry. If that is the case, what guarantees that both transactions touch rows in the same order. That is, what guarantees that these two updates do not deadlock?  

I don't think I've ever encountered in 25 years two bulk update statements deadlocking by themselves. But what exactly has been saving me?  

Thanks in advance!  

Matt      

--
http://www.freelists.org/webpage/oracle-l