आप Web Locks API के साथ विभिन्न टैब्स के बीच शेयर्ड कार्य का समन्वय (coordinate) कैसे करते हैं?

1. प्रश्न

एक ही ओरिजिन (same-origin) वाले कई टैब एक साथ IndexedDB कैश को रिफ्रेश कर सकते हैं और सर्वर के साथ सिंक्रोनाइज़ कर सकते हैं। एक ऐसा समन्वयक (coordinator) डिज़ाइन करें जो अधिक से अधिक एक संदर्भ (context) को सिंक्रोनाइज़ करने दे, जबकि अन्य प्रतीक्षा करें, छोड़ दें (skip), या रिलीज़ के बाद पुन: जाँच करें। इसमें टैब बंद होना, नेटवर्क त्रुटियां और Web Locks रहित ब्राउज़र शामिल होने चाहिए।

2. बाधाएं और स्पष्टीकरण

लॉक का नाम एक ही ओरिजिन वाले विंडोज़ और वर्कर्स के बीच साझा किया जाता है।
लॉक केवल एसिंक्रोनस कॉलबैक के समन्वय स्कोप की सुरक्षा करता है; यह कोई डेटाबेस ट्रांसैक्शन या सर्वर-साइड समवर्ती नियंत्रण (concurrency control) नहीं है।
सिंक्रोनाइज़ेशन में समय लग सकता है, इसलिए इसे कैंसलेशन, पुनः प्रयास (retries), और एक संस्करण या परिणाम ब्रॉडकास्ट की आवश्यकता होती है।
लॉक के लिए प्रतीक्षा करने, तुरंत जाँच करने (probing), और अनुरोध को छोड़ने (abandoning) के बीच अंतर स्पष्ट करें।

3. मुख्य दृष्टिकोण

नामित लॉक का अनुरोध करने के लिए navigator.locks.request(name, options, callback) को कॉल करें। कॉलबैक Promise के सेटल होने के बाद लॉक रिलीज़ हो जाता है, इसलिए कॉलबैक में पूर्ण रीड, सिंक और स्टेट-राइट फ़्लो शामिल होना चाहिए। एक डिफ़ॉल्ट अनुरोध कतारबद्ध (queue) होता है; व्यस्त होने पर ifAvailable: true, null के साथ वापस कॉल करता है; signal उस अनुरोध को रद्द कर सकता है जो अभी भी प्रतीक्षा कर रहा है।

लॉक मैनेजर उस संदर्भ के समाप्त होने पर लॉक को रिलीज़ कर देता है जिसका वह स्वामित्व रखता है, लेकिन शुद्धता (correctness) केवल टैब क्रैश क्लीनअप पर निर्भर नहीं होनी चाहिए। सिंक रिकॉर्ड्स में एक वर्शन, लीज़ या आइडम्पोटेंसी कुंजी होनी चाहिए, और सर्वर को अभी भी राइट्स को सत्यापित करना चाहिए। अन्य टैब BroadcastChannel के माध्यम से या IndexedDB को दोबारा पढ़कर नया वर्शन जान सकते हैं।

4. संदर्भ कार्यान्वयन

javascript

const LOCK = "shared-cache-sync";

async function runSync(signal) {
  return navigator.locks.request(LOCK, { signal }, async (lock) => {
    if (!lock) return { status: "busy" };
    const current = await readSyncVersion();
    if (await isFresh(current)) return { status: "fresh" };
    const result = await fetchAndWriteCache({ signal, baseVersion: current });
    await publishVersion(result.version);
    return { status: "updated", version: result.version };
  });
}

async function trySyncWithoutWaiting() {
  return navigator.locks.request(
    LOCK,
    { ifAvailable: true },
    (lock) => lock ? runOneSync() : { status: "busy" },
  );
}

5. शुद्धता और विफलता से निपटना

लॉक नामित रिसोर्स के लिए समान-ओरिजिन संदर्भों के बीच पारस्परिक अपवर्जन (mutual exclusion) प्रदान करता है; यह किसी नेटवर्क अनुरोध या डेटाबेस राइट को रोलबैक नहीं करता है। सशर्त अपडेट से पहले वर्शन को दोबारा पढ़ें। यदि नेटवर्क विफल हो जाता है, तो थ्रो (throw) करें ताकि लॉक रिलीज़ हो जाए और बाद का अनुरोध पुन: प्रयास कर सके। कॉलबैक के बाहर "हम लॉक के स्वामी हैं" बूलियन को स्टोर न करें।

जब कोई AbortSignal किसी प्रतीक्षारत अनुरोध को रद्द करता है, तो कॉल करने वालों को कैंसलेशन और व्यावसायिक विफलता (business failure) के बीच अंतर करना चाहिए। लंबी प्रतीक्षा के लिए, दिखाएं कि कोई अन्य टैब सिंक्रोनाइज़ कर रहा है या कार्य छोड़ दें; रिलीज़ के बाद, डुप्लिकेट रिफ्रेश से बचने के लिए वर्शन को दोबारा पढ़ें। एक BroadcastChannel अधिसूचना केवल एक अनुकूलन (optimization) है; IndexedDB या सर्वर ही आधिकारिक बना रहता है।

6. फ़ॉलो-अप और जाल

Web Locks केवल समान-ओरिजिन संदर्भों का समन्वय करता है; यह किसी अन्य साइट, सर्वर प्रक्रिया या डेटाबेस पंक्ति को लॉक नहीं कर सकता।
ifAvailable कतार में नहीं लगता है। एक व्यस्त अनुरोध null प्राप्त करता है, जो कि एक सामान्य परिणाम है।
steal: true मौजूदा कतार सिमेंटिक्स को तोड़ता है और इसे वर्शन जांच वाले स्पष्ट रूप से डिस्पोजेबल कार्य तक ही सीमित रखा जाना चाहिए।
API के बिना, BroadcastChannel और IndexedDB सर्वोत्तम-प्रयास (best-effort) समन्वय प्रदान कर सकते हैं, समान पारस्परिक-अपवर्जन गारंटी नहीं; सर्वर को अभी भी डिडुप्लिकेशन की आवश्यकता होती है।

7. आगे पढ़ना

Web Locks, IndexedDB ट्रांसैक्शन, Service Worker संदेशों और BroadcastChannel की तुलना करें: लॉक्स क्रॉस-कॉन्टेक्स्ट अपवर्जन प्रदान करते हैं, ट्रांसैक्शन सिंगल-डेटाबेस परमाणुकता (atomicity) प्रदान करते हैं, और चैनल्स अधिसूचना प्रदान करते हैं। क्रॉस-डिवाइस या क्रॉस-यूज़र अपवर्जन सर्वर लीज़, आइडम्पोटेंट APIs या डेटाबेस बाधाओं (constraints) के अंतर्गत आता है।

8. साक्षात्कार स्कोरिंग बिंदु

लॉक स्कोप बताने में सक्षम होना

उम्मीदवार को यह बताना चाहिए कि एक नामित लॉक समान-ओरिजिन विंडोज़ और वर्कर्स का समन्वय करता है, कॉलबैक Promise के सेटल होने पर रिलीज़ होता है, और सर्वर या डेटाबेस समवर्ती नियंत्रण (concurrency control) को प्रतिस्थापित नहीं कर सकता है।

अनुरोध मोड में अंतर करने में सक्षम होना

उन्हें डिफ़ॉल्ट कतार (queuing), तत्काल ifAvailable प्रोबिंग, और AbortSignal के साथ प्रतीक्षा छोड़ने की व्याख्या करनी चाहिए।

क्रैश और डुप्लिकेट को संभालने में सक्षम होना

उन्हें वर्शन, आइडम्पोटेंसी कीज़ और सशर्त राइट्स का उपयोग करना चाहिए, यह बताते हुए कि टैब क्रैश क्लीनअप व्यावसायिक राइट्स को रोलबैक नहीं करता है।

एक ईमानदार फ़ॉलबैक देने में सक्षम होना

उन्हें एक BroadcastChannel/IndexedDB सर्वोत्तम-प्रयास (best-effort) पथ प्रदान करना चाहिए और यह बताना चाहिए कि पारस्परिक अपवर्जन कमजोर है जबकि सर्वर सुरक्षा उपाय अनिवार्य रहते हैं।