आप मूल रूप से एक शास्त्रीय कतार आधारित वर्कफ़्लो का वर्णन कर रहे हैं, और आपको वास्तविक का उपयोग करने पर विचार करना चाहिए। कतार .
चर्चा के लिए, यहां बताया गया है कि आप जो चाहते हैं उसे कैसे प्राप्त करते हैं:
- विशिष्ट संसाधन का दावा करें:
SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK) WHERE key = @key. यदि संसाधन पर पहले से ही दावा किया गया है तो अवरुद्ध कर देगा। यदि संसाधन पर पहले से ही दावा किया गया है तो अपवाद वापस करने के लिए लॉक टाइमआउट का उपयोग करें।keyचाहिए अनुक्रमित और अद्वितीय बनें। - अगला उपलब्ध संसाधन:
SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK, READPAST) ORDER BY <accessorder>. संसाधनों की वरीयता (सबसे पुरानी, सर्वोच्च प्राथमिकता आदि) को व्यक्त करने के लिए आपको एक आदेश को परिभाषित करना होगा - एक दावा किया गया संसाधन जारी करें:
COMMITआपका लेन-देन।
समस्या का सार सही लॉक संकेतों का उपयोग करना है, और इस तरह की समस्या को हल करने के लिए स्पष्ट लॉक संकेतों की आवश्यकता होती है। UPDLOCK 'दावा' लॉक के रूप में कार्य करेगा। ROWLOCK सर्वर को पेज लॉक में 'ऑप्टिमाइज़' करने से रोकने के लिए सही ग्रैन्युलैरिटी बनाता है। READPAST आपको दावा किए गए संसाधनों को छोड़ने की अनुमति देता है। पंक्तियों पर UPDLOCK रखने से पंक्ति लॉक हो जाएगी और आपको बाद में इसे अपडेट करने की अनुमति मिल जाएगी, लेकिन सामान्य रीड-प्रतिबद्ध चयन जैसे अन्य कार्यों को रोक दिया जाएगा जो लॉक की गई पंक्ति पर अवरुद्ध हो जाएंगे। हालांकि विचार यह है कि आप वैसे भी पंक्ति को अद्यतन करने जा रहे हैं, जो एक अपरिहार्य एक्स लॉक रखेगा। यदि आप तालिका को अधिक उपलब्ध रखना चाहते हैं तो आप ऐप लॉक इसके बजाय, लेकिन सही ढंग से खींचना काफी कठिन है। आपको संसाधन पर एक स्ट्रिंग डिस्क्रिप्टर पर ऐप लॉक का अनुरोध करना होगा, जैसे कुंजी मान, या CHECKSUM कुंजी का या यह %%LOCKRES%%
मूल्य। ऐप लॉक आपको 'सत्र' के दायरे में ऐप लॉक का अनुरोध करके लेनदेन से 'दावे' के दायरे को अलग करने की अनुमति देता है, लेकिन फिर आपको मैन्युअल रूप से दावा जारी करना होगा ('लेनदेन' स्कोप्ड ऐप लॉक प्रतिबद्ध समय पर जारी किए जाते हैं) . हालांकि सावधान रहें, ऐप लॉक के साथ अपने आप को पैर में गोली मारने के एक हजार तरीके हैं।
