Why should you care?

Concurrent transfers that lock accounts in opposite order deadlock under load.

See it live — copy this example

Run in SQL Server Management Studio (SSMS) or Azure Data Studio.

-- Classic deadlock pattern (two windows)
-- A: BEGIN TRAN; UPDATE Accounts SET Balance=Balance WHERE AccountId=1;
-- B: BEGIN TRAN; UPDATE Accounts SET Balance=Balance WHERE AccountId=2;
-- A: UPDATE Accounts SET Balance=Balance WHERE AccountId=2; -- waits
-- B: UPDATE Accounts SET Balance=Balance WHERE AccountId=1; -- deadlock

SELECT * FROM sys.dm_exec_session_wait_stats
WHERE session_id = @@SPID; -- after tests, look for LCK waits

What happened?

• Comments show the cycle.
• One session becomes the victim.
• Capture deadlock graphs with Extended Events for real incidents.

Practice next

1. Reproduce carefully in lab with two windows.
2. Note error 1205 on the victim.
3. Retry logic belongs in the app/proc.
4. Always lock AccountId in ascending order in both procs.
5. Reduce transaction scope to fewer statements.

Remember

Deadlock = circular lock wait. Engine kills a victim. Capture graphs; fix ordering.

Transfer deadlocks at noon

DataVerse transfers locked accounts inconsistently.

Outcome: Ordered locking cut deadlocks near zero.