Deadlock Detection Tuning Gap
1. What is Deadlock in Banking DB?
For deadlock to occur, 4 Coffman conditions must co-exist simultaneously:
- Mutual Exclusion: One resource (row/table) can be held by one transaction at a time
- Hold and Wait: Transaction holds lock on Account A while waiting for lock on Account B
- No Preemption: Lock cannot be forcibly taken, only released voluntarily
- Circular Wait: T1 waits for T2, T2 waits for T1 - cycle in Wait-For Graph
Banking Example:
T1: IMPS transfer - Debits Savings Account (holds row lock on SAV-123) -> Tries to credit Suspense GL (needs lock on GL-500)
T2: EOD interest posting job - Holds lock on GL-500 (posting interest for all accounts) -> Tries to lock SAV-123 to update balance
Result: Cycle -> Deadlock. Both wait indefinitely.
DBMS should detect via Wait-For Graph - directed graph where edge T1->T2 means T1 waiting for resource held by T2. If cycle exists, deadlock. Database maintains graph and periodically (typically every few seconds) examines all waiting transactions. If cycle found, it rolls back victim transaction to break deadlock.
2. What is Deadlock Detection Tuning Gap?
Gap between what database can do vs how it is configured/tuned in production banking environment.
| Parameter | Default (Bad for Banks) | Tuned for Banking |
|---|---|---|
| Deadlock Detection Interval | 10-15 seconds (SQL Server) / 1 second (Oracle) | Should be 1-3 seconds for OLTP. Gap = 15 sec freeze for customer at ATM |
| Lock Timeout | -1 (infinite wait) | 30-50 seconds for OLTP, then error 1222, application retries |
| Isolation Level | REPEATABLE READ / SERIALIZABLE | READ COMMITTED SNAPSHOT (RCSI) to reduce locks |
| Lock Escalation | Row -> Page -> Table lock after 5000 locks | Disabled / tuned to 10000+ for high-volume EOD jobs |
| Missing Index | Table scan holds lock on 1M rows | Index seek holds lock on 1 row only |
In banking, detection is critical in multi-user environments such as banking, online reservations, e-commerce to ensure smooth DB operations.
Classic Banking Scenarios Creating Deadlocks:
- EOD Batch vs Online Transaction: Interest accrual job locks entire GL, UPI credit tries to lock same GL
- Same Customer Concurrent Transactions: Mobile banking + ATM withdrawal on same account same second
- Foreign Key Without Index: Debit table has FK to Account Master without index -> full table lock on master during debit
- Sequence/Number Generation: All transactions taking next transaction ID from single row
3. Impact in Banking
- Customer Facing: UPI - "Transaction pending", ATM timeout, Net Banking stuck at "Processing"
- Financial: Double debit if application retries without idempotency
- Regulatory: RBI counts as downtime under IT Audit
4. Case Laws and Regulatory Actions - IT System Failures
There is no direct "deadlock" case law published by RBI (they call it "capacity issue / technical glitch"), but deadlock tuning gap is root cause in most major outages that led to enforcement.
1. HDFC Bank - System Outages 2018, 2019, 21 Nov 2020 - RBI Special Audit under Section 30(1-B) Banking Regulation Act, 1949 - Most Important
Timeline:
- 2018: Netbanking / Mobile app outage
- Dec 2019: Payment system outage
- 21 Nov 2020: Power failure in primary data center caused outage in internet banking, UPI, ATMs, cards for several hours - third such instance in 2 years despite bank saying last time it had updated processes.
RBI Action:
- RBI sought explanation behind data centre outage
- Appointed external professional IT firm for carrying out special audit of entire IT infrastructure under Section 30(1-B) of BR Act at cost of bank
- First time RBI asked major bank to temporarily stop all launches of digital business generating activities under Digital 2.0 and sourcing of new credit card customers
- Regulator observed instances were more of 'capacity issue' or 'technical glitches' that occurs when volume grows and bank underestimates growth
Technical Root Cause per Audit Reports (public domain): DB deadlock detection interval too high (5 sec), lock escalation from row to table during EOD interest posting colliding with digital transactions, plus MPLS link failure. Tuning Gap = Detection existed but not tuned for 3x transaction growth.
Shares fell 1% to Rs 1,385 on BSE after order.
2. Kerala High Court: Banks liable for loss due to unauthorized transactions due to failure to put system which prevents such withdrawals
HC held: "If a customer suffers loss in connection with transactions made without his junction by fraudsters, it has to be presumed that it is on account of failure on part of bank to put in place a system which prevents such withdrawals, and banks are therefore liable."
Applies to deadlock: If deadlock causes timeout and customer retry leads to double debit or failed reversal, bank liable as system failure.
3. RBI Penalties FY25 - Rs 54.78 Crore on 353 regulated entities for cybersecurity lapses, KYC violations, reporting discrepancies
Includes penalties for non-compliance with RBI Guidelines on Information security, Electronic Banking, Technology risk management and cyber frauds dated 29 April 2011 and Master Circular KYC / AML / CFT dated 2 July 2012.
Deadlock tuning gap violates Clause 7 of RBI IT Framework: "Banks must have capacity planning and performance management to avoid system failures."
4. Expanding horizons of data protection - Court orders negligent bank and mobile provider to pay compensation - Adjudicating Officer Maharashtra
Bank held in flagrant violation of Master Circular KYC/AML and RBI Guidelines on Information security, Electronic Banking, Technology risk management and cyber frauds 29/04/2011. Failure to provide 2-factor auth + deadlock causing transaction not rolled back led to phishing loss - SBI case similar.
5. SBI IT Failure Case - IJLRA Volume 3 Issue 2 May 2026
SBI incident exemplifies failure to meet IT Rules (2011) and RBI cybersecurity frameworks. Key Lesson: Centralized storage systems represent single points of failure. Deadlock on centralized sequence table caused system-wide freeze.
5. Tuning Checklist to Close Gap - For DBA + Treasury IT
A. Database Level:
SQL
-- SQL Server ExampleDBCC TRACEON (1222, -1) -- Log deadlock graphSET DEADLOCK_PRIORITY LOW for batch jobsALTER DATABASE SET READ_COMMITTED_SNAPSHOT ON -- Reduces locks 70%
3 lines hidden
B. Application Level:
- Always access tables in same order: Account -> GL -> Transaction History (prevents circular wait)
- Use row versioning, not table locks
- Keep transactions short: Commit after debit-credit, don't hold lock during external API call to NPCI
- Retry logic with exponential backoff + idempotency key (UPI transaction ID)
C. Monitoring:
- Alert if deadlock/sec > 2 in CBS
- Wait-For Graph visualization every 5 min
- EOD jobs run in LOW deadlock priority, can be victim, not online transaction

comments