A courts deadlock graph shows two clerk procedures accessing docket and payment tables in opposite order. How should the SQL AI developer reduce deadlocks?
Select an answer to reveal the explanation.
Short Explanation
When one clerk locks the docket before payments and another locks payments before the docket, they can deadlock like two people meeting in a narrow hallway. You can prevent that cycle by having both procedures use the same access order.
Full Explanation
The deadlock graph shows the classic opposing-order cycle: one clerk procedure locks docket resources and then waits for payment resources, while another locks payment resources and then waits for docket resources. Standardize both procedures to touch the docket and payment objects in the same order—for example, docket first, then payment—to remove the cycle shown in the graph. Dynamic Data Masking controls which users can see payment amounts; it does not stop SQL from taking locks, so it cannot prevent this deadlock. Anonymous GraphQL mutations that update docket rows outside transactions do not establish a consistent order for the two procedures’ access to docket and payment resources, and bypassing transaction coordination risks inconsistent court data. Lowering every clerk login’s deadlock priority to -10 only makes those sessions more likely to be selected as victims when a deadlock occurs; it does not prevent the cycle and may cause clerk work to fail more often. Exam caveat: consistent ordering must cover the actual locked resources, such as relevant index keys, not just the logical table names. Practical check: compare the resource-acquisition order in both procedures with the deadlock graph, align the procedures, and run concurrent docket-and-payment operations to verify that deadlock events decline while updates remain consistent.