संघर्षों से निपटने के लिए, आपके पास दो विकल्प हैं:
- आप संघर्ष से बचने की कोशिश कर सकते हैं, और यही निराशावादी लॉकिंग करता है।
- या, आप संघर्ष को घटित करने की अनुमति दे सकते हैं, लेकिन आपको अपने लेनदेन करने पर इसका पता लगाने की आवश्यकता है, और यही वह है जो ऑप्टिमिस्टिक लॉकिंग करता है।
अब, आइए निम्नलिखित लॉस्ट अपडेट विसंगति पर विचार करें :
लॉस्ट अपडेट विसंगति पढ़े हुए आइसोलेशन स्तर में हो सकती है ।
ऊपर दिए गए चित्र में हम देख सकते हैं कि ऐलिस का मानना है कि वह उससे 40 वापस ले सकती है accountलेकिन उसे इस बात का अहसास नहीं है कि बॉब ने खाता शेष राशि को बदल दिया है, और अब इस खाते में केवल 20 शेष हैं।
निराशावादी लॉकिंग
निराशावादी ताला खाते पर साझा या पढ़ा ताला लगाकर इस लक्ष्य को प्राप्त करता है इसलिए बॉब को खाता बदलने से रोका जाता है।
ऊपर दिए गए आरेख में, दोनों ऐलिस और बॉब accountटेबल पंक्ति पर एक रीड लॉक प्राप्त करेंगे जो दोनों उपयोगकर्ताओं ने पढ़ा है। डेटाबेस रिपीटेबल रीड या सीरीएबल का उपयोग करते समय SQL सर्वर पर इन तालों को प्राप्त करता है।
क्योंकि एलिस और बॉब दोनों accountने पीके मान के साथ पढ़ा है 1, उनमें से कोई भी इसे तब तक नहीं बदल सकता है जब तक कि एक उपयोगकर्ता रीड लॉक जारी नहीं करता है। ऐसा इसलिए है क्योंकि एक लिखने के ऑपरेशन के लिए राइट / एक्सक्लूसिव लॉक एक्विजिशन की जरूरत होती है, और शेयर / रीड लॉक को राइट / एक्सक्लूसिव लॉक को रोकना होता है।
जब एलिस ने अपना लेन-देन कर लिया और उसके बाद ही रीड लॉक को accountपंक्ति में छोड़ा गया , तो बॉब UPDATEफिर से शुरू करेगा और बदलाव को लागू करेगा। जब तक ऐलिस रीड लॉक जारी नहीं करता, तब तक बॉब के अद्यतन ब्लॉक।
डेटा एक्सेस फ्रेमवर्क अंतर्निहित डेटाबेस निराशावादी लॉकिंग समर्थन का उपयोग करने के तरीके के बारे में अधिक विवरण के लिए, इस लेख को देखें ।
आशावादी ताला
आशावादी लॉकिंग संघर्ष को उत्पन्न करने की अनुमति देता है, लेकिन संस्करण के बदलते ही ऐलिस के अद्यतन को लागू करने पर इसका पता लगाता है।
इस बार, हमारे पास एक अतिरिक्त versionकॉलम है। versionस्तंभ हर बार एक अद्यतन वृद्धि की जाती है या DELETE निष्पादित किया जाता है, और यह भी कहां अद्यतन करने और हटाने के बयानों के खंड में प्रयोग किया जाता है। इसे काम करने के लिए, हमें चयन जारी करने और वर्तमान versionअद्यतन करने से पहले अद्यतन करने की आवश्यकता है, अन्यथा, हमें नहीं पता होगा कि WHERE क्लॉज या वेतन वृद्धि के लिए कौन सा संस्करण मान पास करना है।
डेटा एक्सेस फ्रेमवर्क आशावादी लॉकिंग को कैसे लागू करते हैं, इस बारे में अधिक जानकारी के लिए, इस लेख को देखें ।
अनुप्रयोग स्तर के लेन-देन
70 के दशक के शुरुआती 80 के दशक में रिलेशनल डेटाबेस सिस्टम उभरे हैं, जब एक क्लाइंट, आम तौर पर, टर्मिनल के माध्यम से मेनफ्रेम से कनेक्ट होता है। इसलिए हम अभी भी डेटाबेस सिस्टम को SESSION सेटिंग जैसे शब्दों को परिभाषित करते देखते हैं।
आजकल, इंटरनेट पर, हम अब एक ही डेटाबेस लेनदेन के संदर्भ में पढ़ते और लिखते हैं, और ACID अब पर्याप्त नहीं है।
उदाहरण के लिए, निम्नलिखित उपयोग के मामले पर विचार करें:
आशावादी लॉकिंग के बिना, कोई रास्ता नहीं है यह लॉस्ट अपडेट पकड़ा गया होता, भले ही डेटाबेस लेनदेन Serializable का उपयोग करता हो। ऐसा इसलिए है क्योंकि रीड और राइट को अलग-अलग HTTP अनुरोधों में निष्पादित किया जाता है, इसलिए विभिन्न डेटाबेस लेनदेन पर।
तो, आशावादी लॉकिंग आपको एप्लिकेशन-स्तरीय लेनदेन का उपयोग करते समय भी लॉस्ट अपडेट को रोकने में मदद कर सकता है जो उपयोगकर्ता-सोचने के समय को भी शामिल करता है।
आवेदन-स्तर या तार्किक लेनदेन के बारे में अधिक जानकारी के लिए, इस लेख को देखें ।
निष्कर्ष
आशावादी लॉकिंग एक बहुत ही उपयोगी तकनीक है, और यह कम-सख्त आइसोलेशन स्तरों का उपयोग करते समय भी ठीक काम करता है, जैसे Read Committed, या जब पढ़ता और लिखता है तो बाद के डेटाबेस लेनदेन में निष्पादित होते हैं।
आशावादी लॉकिंग का नकारात्मक पक्ष यह है कि एक को पकड़ने पर डेटा एक्सेस फ्रेमवर्क द्वारा रोलबैक शुरू किया जाएगा OptimisticLockException, इसलिए वर्तमान में निष्पादित लेनदेन द्वारा पहले किए गए सभी कार्यों को खोना।
जितना अधिक विवाद, उतने अधिक संघर्ष और अधिक से अधिक लेनदेन को खत्म करने की संभावना। रोलबैक डेटाबेस प्रणाली के लिए महंगा हो सकता है क्योंकि इसमें सभी वर्तमान लंबित परिवर्तनों को वापस करने की आवश्यकता होती है जिसमें तालिका पंक्तियों और सूचकांक रिकॉर्ड दोनों शामिल हो सकते हैं।
इस कारण से, निराशावादी लॉकिंग अयस्क उपयुक्त हो सकता है जब टकराव अक्सर होता है, क्योंकि यह लेनदेन को वापस करने की संभावना को कम करता है।