হাজার হাজার concurrent transaction-এ deadlock কীভাবে প্রতিরোধ করবেন?

Question

IT Interview Practice · Accepted Answer

**একটি ধারাবাহিক global order-এ lock অর্জন করুন, transaction ছোট রাখুন, নিরাপদ হলে isolation কমান, এবং একটি deadlock তবুও ঘটলে পরাজিতকে retry করুন।** একটি deadlock একটি cycle: transaction A row 1 ধরে এবং row 2-এর জন্য অপেক্ষা করে, যখন B row 2 ধরে এবং row 1-এর জন্য অপেক্ষা করে — কেউই এগোতে পারে না, তাই DB একটিকে হত্যা করে।

## যে cycle আপনাকে ভাঙতে হবে

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## কৌশল

- **ধারাবাহিক lock ordering.** প্রতিটি transaction যদি সর্বদা একই order-এ (যেমন ascending primary key) row lock করে, একটি cycle অসম্ভব — A ও B উভয়ে প্রথমে row 1 ধরে, তাই একজন কেবল অপেক্ষা করে। এটি একক বৃহত্তম lever। একটি ক্লাসিক bug: একটি money transfer যা `(from, to)` order-এ account lock করে বিপরীত transfer-এর সঙ্গে deadlock করে; সর্বদা `min(id), max(id)` দিয়ে lock করুন।
- **ছোট transaction.** যতটা সম্ভব কম সময় lock ধরুন — validation, network call, এবং read `BEGIN`-এর **আগে** করুন, তারপর দ্রুত lock, write ও `COMMIT` করুন। দীর্ঘ transaction cycle ও lock wait-এর window প্রশস্ত করে।
- **নিরাপদ হলে isolation কমান.** `SERIALIZABLE` বেশি/range lock নেয় এবং বেশি deadlock করে; `READ COMMITTED` (Postgres ডিফল্ট) কম lock করে। যে দুর্বলতম isolation এখনও correctness পূরণ করে তা ব্যবহার করুন।
- **Deadlock-এ retry.** Deadlock ক্ষণস্থায়ী। deadlock error ধরুন (Postgres `40P01`, MySQL `1213`) এবং ছোট backoff সহ পুরো transaction retry করুন। scale-এ কিছু contention অনিবার্য, তাই retry একটি safety net, ordering-এর বিকল্প নয়।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়ার যাচাই করেন আপনি জানেন কিনা deadlock **ডিজাইন দ্বারা প্রতিরোধিত, কেবল ধরা নয়**। শুধু "retry" নাম ধরে বলা একটি দুর্বল উত্তর — দারুণ উত্তর **ধারাবাহিক lock ordering** ও **ছোট transaction** দিয়ে নেতৃত্ব দেয়, তারপর residual-এর জন্য retry যোগ করে। একটি সাধারণ ফাঁদ: ধরে নেওয়া যে app-কে deadlock শনাক্ত করতে হবে; বাস্তবে **DB cycle শনাক্ত করে এবং একটি victim abort করে** আপনার জন্য — আপনার কাজ হলো ordering প্লাস একটি retry loop।

**ট্রেড-অফ:** access pattern dynamic হলে বা table জুড়ে বিস্তৃত হলে কঠোর ordering কঠিন হতে পারে; কম isolation anomaly-র (non-repeatable read) ঝুঁকি রাখে যা আপনাকে বিচার করতে হবে। Retry loop অবশ্যই **idempotent** ও capped হতে হবে, নইলে একটি hot conflict একটি retry storm-এ পরিণত হয়। Deadlock prevention আসলে lock-discipline প্লাস একটি bounded retry, একটি একক silver bullet নয়।

যে cycle আপনাকে ভাঙতে হবে

কৌশল

ইন্টারভিউ দৃষ্টিভঙ্গি

সম্পর্কিত প্রশ্ন