Fencing Token
ফেন্সিং টোকেন
Lock-এর সঙ্গে একঘেয়ে বাড়তে থাকা সংখ্যা — storage পুরনো token-এর write ফেলে দেয়, zombie lock-holder নিষ্ক্রিয়।
also: fence-token
Kleppmann-এর ক্লাসিক দৃশ্য:
c1 lock#33 পায় → GC pause-এ জগ খেয়ে বসে
lock expire → c2 lock#34 পায় → write(token=34) ✓
c1 ঘুম থেকে write(token=33) ✗ storage: 33 < 34, reject!- Lock service নিজে যথেষ্ট নয় — fencing-এর ভার storage-side check-এ: token monotonic হতে হবে এবং receiver reject করতেই হবে
- Monotonic source কী? Consensus protocol-এর term+index (Raft) বা lock server-এর atomic counter — আবার consensus-এই ফেরা
- Token ছাড়া lease/lock-এর guarantee আসলে ‘best effort’ — এই শব্দটা design doc-এ লিখলে সৎতাই বাড়ে