🎁 💂🏼 👸🏿 रिलेशनल डेटाबेस के लिए प्रतिस्पर्धी पहुँच 😑 🐨 🏇🏻

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

संबंधपरक डेटाबेस तक प्रतिस्पर्धी पहुंच के मुद्दे लगभग किसी भी एप्लिकेशन सॉफ़्टवेयर डेवलपर्स द्वारा सामना किए जाते हैं और न केवल उन्हें। इस क्षेत्र की मांग का परिणाम बड़ी संख्या में निर्मित वास्तु पैटर्न की उपस्थिति है। यह आपको ऐसे कार्यक्रमों को विकसित करने की महान जटिलता के साथ सफलतापूर्वक सामना करने की अनुमति देता है। नीचे हम ऐसे व्यंजनों के बारे में बात करेंगे, साथ ही उन तंत्रों के बारे में जिन पर उनका कार्यान्वयन आधारित है। कथा का चित्रण जावा कोड उदाहरणों के साथ किया जाएगा, लेकिन अधिकांश सामग्री भाषा-विशिष्ट नहीं है। लेख का उद्देश्य विषय के पूर्ण कवरेज के बजाय विषय से परिचय के रूप में संबंधपरक डेटाबेस तक प्रतिस्पर्धी पहुंच की समस्याओं का वर्णन करना है।

प्रतिस्पर्धात्मक पहुँच मुद्दे

स्थिति पर विचार करें। एक निश्चित लेखा प्रणाली में, दस्तावेजों की होल्डिंग के दौरान माल के संतुलन में परिवर्तन को प्रतिबिंबित करना आवश्यक है। चर्चा को और अधिक ठोस बनाने के लिए, मैं इसे PostgreSQL पर चल रहे उदाहरणों के साथ आपूर्ति करूँगा। यहां हमारे अकाउंटिंग सिस्टम और टेस्ट डेटा के लिए डेटाबेस संरचना है।

CREATE TABLE stocks ( id integer PRIMARY KEY, name varchar(256) NOT NULL, quantity decimal(10,2) NOT NULL DEFAULT 0.0 ); CREATE TABLE documents ( id integer PRIMARY KEY, quantity decimal(10,2) NOT NULL DEFAULT 0.0, processed boolean NOT NULL DEFAULT false, stock integer REFERENCES stocks ); INSERT INTO stocks (id, name, quantity) VALUES (1, '', 56.4), (2, '', 26.8); INSERT INTO documents (id, quantity, stock) VALUES (1, 15.6, 1), (2, 26.1, 1);

मान लीजिए कि गोदाम से माल लिखने के लिए हमारा दस्तावेज जिम्मेदार है। एप्लिकेशन कोड दस्तावेज़ के डेटा को लोड करता है और शेष, गणना करता है और डेटा को डेटाबेस में संग्रहीत करता है। यदि यह कार्रवाई एक आवेदन द्वारा की जाती है, तो सब कुछ क्रम में है।

 SELECT quantity, processed, stock FROM documents WHERE id = 1;

  quantity | processed | stock ----------+-----------+------- 15.60 | f | 1

 SELECT name, quantity FROM stocks WHERE id = 1;

  name | quantity ------+----------  | 56.40

पहचानकर्ता 1 और शेष के साथ दस्तावेज़ का डेटा लोड किया जाता है। शेष का नया मूल्य 56.40 - 15.60 = 40.80 लिखकर गणना की गई थी और दस्तावेज़ के प्रसंस्करण के बारे में एक नोट के साथ डेटा को वापस सहेजा गया था।

 UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1;

लेकिन सिंगल-यूजर सिस्टम एक लंबा अतीत है। अब ऐसे व्यावसायिक अनुप्रयोग की कल्पना करना असंभव है जिसके साथ उपयोगकर्ताओं को काम करना चाहिए। इसलिए, उस स्थिति पर विचार करें जब एक ही समय में दो दस्तावेज़ संसाधित किए जाते हैं। जैसा कि पहले मामले में, एप्लिकेशन डेटाबेस से डेटा पढ़ते हैं।

पहला आवेदन

 SELECT quantity, processed, stock FROM documents WHERE id = 1;

  quantity | processed | stock ----------+-----------+------- 15.60 | f | 1

 SELECT name, quantity FROM stocks WHERE id = 1;

  name | quantity ------+----------  | 56.40

दूसरा आवेदन

 SELECT quantity, processed, stock FROM documents WHERE id = 2;

  quantity | processed | stock ----------+-----------+------- 26.10 | f | 1

 SELECT name, quantity FROM stocks WHERE id = 1;

  name | quantity ------+----------  | 56.40

और यहां एक स्पष्ट समस्या उत्पन्न होती है: पहला आवेदन 56.40 - 15.60 = 40.80 और दूसरा 56.40 - 26.10 = 30.30 की गणना करता है। और इनमें से कोई भी परिणाम डेटाबेस को लिखा जाएगा। जिसके लिए अंतिम अद्यतन अनुरोध निष्पादित किया जाएगा। यह स्पष्ट रूप से वह नहीं है जो उपयोगकर्ता देखने की उम्मीद करता है। इस तरह की समस्याओं को समानांतर प्रोग्रामिंग में अच्छी तरह से जाना जाता है और इसे दौड़ की स्थिति कहा जाता है। यह मामला सामान्य नाम रीड-संशोधित-राइट के तहत एक समग्र कार्रवाई है।

यदि हमने प्रसंस्करण (संसाधित क्षेत्र) के लिए दस्तावेज़ की जाँच की, और एक वास्तविक आवेदन में हमें ऐसा करना पड़ा, तो ऐसी स्थिति हो सकती है, जिसमें जाँच के बावजूद, दस्तावेज़ को दो बार संसाधित किया जा सकता है। सब कुछ एक दौड़ की स्थिति भी है, लेकिन एक अलग तरह का चेक-तब-एक्ट ऑपरेशन। इसके अलावा, अद्यतन अनुरोधों के बीच के अंतराल में, डेटाबेस असंगत स्थिति में है, अर्थात, दस्तावेज़ कार्रवाई पहले ही पूरी हो चुकी है, लेकिन दस्तावेज़ को संसाधित के रूप में चिह्नित नहीं किया गया है।

परिणामस्वरूप, हमारे पास दो सबसे आम समस्याएं हैं जो डेटाबेस में गलत प्रतिस्पर्धात्मक पहुंच के साथ होती हैं। यह उन परिवर्तनों का नुकसान है जो पढ़ने-बदलने-लिखने की दौड़ की स्थिति की स्थिति में होते हैं। और अद्यतन अनुरोधों के बीच डेटा की असंगत स्थिति।

DBMS तंत्र

संबंधपरक डेटाबेस तक प्रतिस्पर्धी पहुंच के लिए विशिष्ट व्यंजनों पर चर्चा करने के लिए, आपको निम्न-स्तरीय तंत्र से परिचित होना होगा जो DBMS और प्रोग्रामिंग सिस्टम प्रदान करते हैं। ये तकनीकी तत्व हैं, जिन पर कार्यान्वयन आधारित है। मुख्य तत्व लेनदेन और ताले हैं। हम आगे उनकी चर्चा करेंगे।

लेनदेन और अलगाव के स्तर

लेन-देन एक डेटाबेस के साथ बातचीत के लिए संचालन का एक एकल अनुक्रम है, जिसे एक के रूप में माना जाता है, लेनदेन को वापस करने या पुष्टि करने की क्षमता के साथ। एक लेन-देन परिवर्तन की स्थिरता के मुद्दे को हल करने का एक साधन हो सकता है, और रेसिंग स्थितियों को भी अनुमति नहीं देता है। पहली या दोनों समस्याओं को हल करने के लिए लेनदेन की उपयुक्तता अलगाव स्तर पर निर्भर करती है। अलगाव एक संपत्ति है जो परिभाषित करता है कि कैसे / जब एक एकल ऑपरेशन द्वारा किए गए परिवर्तन एक प्रतिस्पर्धी ऑपरेशन को दिखाई देंगे।

SQL मानक चार आइसोलेशन स्तरों को परिभाषित करता है: बिना पढ़े, पढ़े गए, दोहराए गए, पढ़े जाने वाले, परिवर्तनशील। इन सभी में इन्सुलेशन का न्यूनतम स्वीकार्य स्तर है। इन स्तरों के मूल गुणों को नाम से स्पष्ट होना चाहिए। अलग-अलग डीबीएमएस अलग-अलग तरीकों से अलगाव के लिए समर्थन को लागू कर सकते हैं। मुख्य बात यह है कि प्रत्येक कार्यान्वयन अलगाव की अनुमति नहीं देता है जो स्तर के लिए निर्धारित की तुलना में कम कठोर है। उदाहरण के लिए, PostgreSQL आंतरिक रूप से केवल दो अलग-अलग स्तरों का समर्थन करता है: प्रतिबद्ध और अनुक्रमिक पढ़ें। ऊपर दिए गए उदाहरणों में वर्णित समस्याओं को हल करने के लिए इन अलगाव स्तरों का उपयोग करने पर विचार करें।

रीड किए गए आइसोलेशन लेवल (PostgreSQL में डिफ़ॉल्ट रूप से प्रयुक्त) का उपयोग करना असंगत डेटा स्थिति की समस्या को हल करता है। यह इस तथ्य के कारण हासिल किया जाता है कि लेनदेन के भीतर किए गए सभी परिवर्तन वर्तमान एक के बाद प्रतिस्पर्धी लेनदेन के लिए दिखाई देते हैं।

 BEGIN; SELECT quantity, processed, stock FROM documents WHERE id = 1; SELECT name, quantity FROM stocks WHERE id = 1; --    UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1; COMMIT;

लेकिन इस तरह के लेनदेन से परिचालन के प्रतिस्पर्धी निष्पादन में दौड़ की स्थिति के साथ समस्या का समाधान नहीं होता है। ऐसी स्थितियों में, अलगाव का एक और स्तर, सीरियल करने योग्य, मदद कर सकता है। यह एक संभव समाधान है, लेकिन यह केवल एक ही नहीं है। PostgreSQL में Serializable अलगाव स्तर के कार्यान्वयन का व्यवहार पूरी तरह से नाम के अनुरूप नहीं है। यही है, एक अनुक्रमिक अलगाव स्तर के साथ सभी लेनदेन क्रमिक रूप से निष्पादित नहीं किए जाते हैं। इसके बजाय, लेन-देन करते समय, डेटा को बदलने पर एक विरोधाभास की जाँच की जाती है, और यदि डेटा को पहले ही एक प्रतिस्पर्धी लेनदेन द्वारा बदल दिया गया है, तो वर्तमान लेनदेन विफल हो जाता है।

 BEGIN ISOLATION LEVEL SERIALIZABLE; SELECT quantity, processed, stock FROM documents WHERE id = 1; SELECT name, quantity FROM stocks WHERE id = 1; --    UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1; COMMIT;

उपरोक्त लेनदेन रेसिंग स्थिति और डेटा स्थिरता दोनों के साथ समस्या को हल करता है। इस दृष्टिकोण की एक विशिष्ट विशेषता यह है कि इस लेनदेन को निष्पादित करने वाला कोड लेन-देन पूरा होने के बाद ही सफलता के बारे में सीखता है। और विफलता के परिणामस्वरूप, लेनदेन के सफल होने तक सभी कार्यों और गणनाओं को दोहराना आवश्यक होगा, या कार्रवाई करने से इनकार करने का निर्णय लिया जाता है। यह व्यवहार एक बड़े प्रतिस्पर्धी भार के साथ असंतोषजनक है, क्योंकि पुनरावृत्ति के लिए बड़ी मात्रा में संसाधनों का उपभोग किया जाएगा। इस व्यवहार को आशावादी संगरोध नियंत्रण कहा जाता है।

उपरोक्त उदाहरण इस धारणा पर आधारित हैं कि व्यावसायिक तर्क पूरी तरह से एप्लिकेशन कोड में लागू किया जाता है, और डेटाबेस केवल भंडारण के रूप में कार्य करता है।
प्रदर्शन को प्रभावित करने वाले लेनदेन के उपयोग में एक महत्वपूर्ण विवरण उनकी लंबाई है। लेन-देन बहुत लंबा नहीं होना चाहिए, वे जितनी तेजी से पूरा हो जाएंगे, उतना ही अधिक सिस्टम का प्रदर्शन होगा। यह टिप्पणी उस कोड के लिए महत्वपूर्ण नहीं हो सकती है जो उपयोगकर्ताओं की एक छोटी संख्या के साथ एक आवेदन में एक दस्तावेज़ को संपादित करता है। लेकिन यह महत्वपूर्ण है, उदाहरण के लिए, एक वेब सेवा की स्थिति में जो एक डेटाबेस के साथ बातचीत करता है और बड़ी संख्या में ग्राहकों द्वारा उपयोग किया जाता है।

अवरुद्ध

समानांतर प्रोग्रामिंग में, निष्पादन थ्रेड को नियंत्रित करने के लिए एक लॉक तंत्र का उपयोग किया जाता है। ताले आपको विशिष्ट क्षेत्रों तक पहुंच को अनुक्रमित करने की अनुमति देते हैं। DBMSs डेटा तक पहुंच को नियंत्रित करने के लिए लॉकिंग मैकेनिज्म का भी समर्थन करते हैं। आइए PostgreSQL के उदाहरण का उपयोग करके इस तंत्र की संभावनाओं पर विचार करें।

PostgreSQL कई तरह के तालों का समर्थन करता है। उनकी मुख्य विशिष्ट विशेषता कई प्रकार के ताले हैं जिनके साथ वर्तमान प्रकार का लॉक टकराव करता है। संघर्ष का मतलब है कि वर्तमान लॉक को किसी भी प्रकार के परस्पर विरोधी प्रकार के लॉक के साथ कैप्चर नहीं किया जा सकता है। इसके अलावा, ताले स्पष्ट और अंतर्निहित में विभाजित हैं। स्पष्ट ताले वे हैं जो उपयोगकर्ता द्वारा निर्दिष्ट अन्य शब्दों में अद्यतन के लिए या शेयर के लिए लॉक कीवर्ड और क्वेरी संशोधक का उपयोग करके क्वेरी में निष्पादित किए जाते हैं। निहित ताले वे होते हैं जो विभिन्न अनुरोधों के दौरान कैप्चर किए जाते हैं (चयन, अद्यतन, सम्मिलित करें, बदल सकते हैं और अन्य)। PostgerSQL एक अलग प्रकार के लॉक का भी समर्थन करता है जिसे सलाहकार लॉक कहा जाता है।

वर्तमान लेनदेन के अंत तक अनुरोध निष्पादित होने के समय से ताले पर कब्जा कर लिया जाता है। उदाहरण के लिए, हमारी काल्पनिक लेखा प्रणाली में, स्टॉक तालिका की पंक्ति पर एक विशेष लॉक को कैप्चर करना संभव था, जिसके शेष संचालन के लिए और दस्तावेज़ तालिका की पंक्ति पर, जिससे यह सुनिश्चित होता है कि केवल वर्तमान लेनदेन की इस डेटा तक पहुंच है।

 BEGIN; SELECT quantity, processed, stock FROM documents WHERE id = 1 FOR UPDATE; SELECT name, quantity FROM stocks WHERE id = 1 FOR UPDATE; --    UPDATE stocks SET quantity = 40.80 WHERE id = 1; UPDATE documents SET processed = true WHERE id = 1; COMMIT;

ऊपर दिए गए कोड दस्तावेजों और स्टॉक टेबल में पंक्तियों पर ताले लगाते हैं। इस मामले में, अपडेट के लिए कीवर्ड चुनिंदा डेटा को चुनने के लिए क्वेरी में जोड़े जाते हैं। यह अद्यतन करने के लिए लाइन का स्पष्ट अवरोधन है। इस मामले में एक पूरी तालिका को अवरुद्ध करना प्रभावी नहीं है। सामान्य तौर पर, इसमें डेटा वाले बड़े पैमाने पर संचालन के लिए एक तालिका को केवल लॉक करने की आवश्यकता होती है, और ये काफी दुर्लभ मामले हैं। अन्यथा, आपको प्रतिस्पर्धात्मक पहुंच के साथ एक प्रदर्शन समस्या मिलती है, क्योंकि इसके लिए सभी कॉल क्रमबद्ध हैं।

जब आप पहले से ही लॉक किए गए क्षेत्र पर लॉक को कैप्चर करने का प्रयास करते हैं, तो लॉक जारी होने तक अनुरोध को अवरुद्ध (डिफ़ॉल्ट रूप से) किया जाता है, या गतिरोध की स्थिति में, त्रुटि संदेश वापस आ जाता है। अवरुद्ध अनुरोध से नियंत्रण वापस करने के लिए अंतराल को सेट करना संभव है, या लॉक (Nowait) पर कब्जा करने की असंभवता के बारे में तुरंत एक संदेश प्राप्त होता है।

प्रतिस्पर्धी नियंत्रण के प्रकार

प्रतिस्पर्धी नियंत्रण वह नियम है जिसके द्वारा प्रतिस्पर्धी साइटों पर निष्पादन के समानांतर सूत्र बातचीत करते हैं। प्रतिस्पर्धी नियंत्रण को गणना किए गए परिणाम की शुद्धता की गारंटी देनी चाहिए। एक अतिरिक्त लक्ष्य किसी विशेष मामले में जल्दी से जल्दी परिणाम प्राप्त करना है। प्रतिस्पर्धी नियंत्रण आमतौर पर प्रसंस्करण संघर्षों के समय के अनुसार प्रकारों में विभाजित होता है: आशावादी (आशावादी), निराशावादी (निराशावादी) और आंशिक रूप से आशावादी (अर्ध-आशावादी)।

आशावादी प्रतिस्पर्धी नियंत्रण में एक कार्रवाई में संभावित संघर्ष के लिए जाँच शामिल है। उदाहरण के लिए, उपयोगकर्ता रिपॉजिटरी से कुछ डेटा का अनुरोध करता है और इसे बदलता है, जिसके बाद वह अपने परिवर्तनों को सहेजने की कोशिश करता है। यदि रिपॉजिटरी में डेटा का वर्तमान संस्करण डेटा के उस संस्करण से मेल खाता है जिसके आधार पर परिवर्तन हुए हैं, तो कोई संघर्ष नहीं है और डेटा को बचाया जा सकता है। विपरीत मामले में, एक संघर्ष उत्पन्न होता है, जिसे या तो कार्रवाई को फिर से निष्पादित करके या उन्हें मना करके संसाधित किया जाता है। आशावादी प्रतिस्पर्धात्मक नियंत्रण प्रतिस्पर्धी पहुंच के लिए अपेक्षाकृत कम प्रतिस्पर्धा के साथ अच्छा प्रदर्शन प्रदान करता है।

निराशावादी प्रतिस्पर्धी नियंत्रण में एक कार्रवाई करने से पहले संभावित संघर्ष की जांच करना शामिल है। यही है, निष्पादन के प्रतिस्पर्धी धागे संरक्षित क्षेत्र पर क्रमबद्ध हैं। यह प्रतिस्पर्धी पहुंच के लिए उच्च प्रतिस्पर्धा के साथ अधिक उत्पादकता प्रदान करता है।

आंशिक रूप से आशावादी एक मिश्रित प्रकार है जिसमें दोनों दृष्टिकोण एक साथ लागू होते हैं।

वास्तु पैटर्न

इस बिंदु पर, पाठक को प्रतिस्पर्धी अभिगम और उन्हें हल करने के लिए DBMS तंत्र के साथ समस्याओं का एक सामान्य विचार होना चाहिए। यह खंड वास्तुशिल्प पैटर्न पर ध्यान केंद्रित करेगा जो डेटाबेस तक प्रतिस्पर्धी पहुंच की समस्याओं के समाधान का प्रतिनिधित्व करता है। नीचे एक पूर्ण विवरण नहीं है, केवल एक सामान्य विचार और एक उदाहरण है। पूर्ण विवरण के लिए, लेख के नीचे दिए गए लिंक पर क्लिक करें।

DBMS के साथ काम करते समय, डेटा को एप्लिकेशन की मेमोरी में लोड किया जाता है, क्रियाओं को उनके साथ या उनके ऊपर ले जाया जाता है, और एक नियम के रूप में, कार्यों का परिणाम वापस बचाया जाना चाहिए। इस समय यह जानने के लिए कि क्या परिवर्तन हुआ है, डेटा पर परिवर्तनों के बारे में जानकारी संग्रहीत करना आवश्यक है। इसके अलावा, निर्मित और हटाए गए ऑब्जेक्ट के बारे में जानकारी संग्रहीत करना आवश्यक है। बेशक, आप डेटाबेस में होने वाले सभी परिवर्तनों को जल्द से जल्द प्रतिबिंबित कर सकते हैं। इस मामले में, निम्नलिखित समस्याएं उत्पन्न होती हैं: सिस्टम लेनदेन में बहुत लंबा समय लगता है, जो प्रतिस्पर्धी पहुंच के दौरान संघर्ष का कारण बनता है, क्योंकि डेटाबेस में परिवर्तन से अधिक लेन-देन के दौरान ताले लगे रहते हैं; डेटाबेस के साथ बातचीत कई छोटे भागों में विभाजित है, जो अप्रभावी भी है। डेटा परिवर्तन पर नज़र रखने की समस्याओं को हल करने के लिए, कार्य पैटर्न की इकाई का वर्णन किया गया है। यह पैटर्न एक ऐसी वस्तु का वर्णन करता है जो सभी परिवर्तनों को ट्रैक करता है और किए गए परिवर्तनों के साथ अपने राज्य को समेटने के लिए डेटाबेस में उन्हें लागू कर सकता है।

 public class UnitOfWork { private List<DomainObject> newObjects; private List<DomainObject> updatedObjects; private List<DomainObject> deletedObjects; /** *   * @return     */ public DomainObject create() { DomainObject domainObject = new DomainObject(); newObjects.add(domainObject); return domainObject; } /** *     * @param domainObject   */ public void update(DomainObject domainObject) { updatedObjects.add(domainObject); } /** *     * @param domainObject   */ public void remove(DomainObject domainObject) { deletedObjects.add(domainObject); } /** *      */ public void commit() { // SQL     INSERT insert(newObjects); // SQL     UPDATE udpate(updatedObjects); // SQL     DELETE delete(deletedObjects); } //  insert, update, delete   }

ऊपर यूनिट ऑफ़ वर्क पैटर्न का सरलतम कार्यान्वयन है। DomainObjects एक UnitOfWork ऑब्जेक्ट के साथ रजिस्टर कर सकते हैं जब उन पर उचित कार्रवाई की जाती है। व्यावसायिक लेन-देन पूरा होने के बाद, अनुप्रयोग UnitOfWork ऑब्जेक्ट पर कमिट विधि को कॉल करता है।
एक व्यवसाय लेनदेन में आमतौर पर लंबा समय लगता है। एक नियम के रूप में, यह कई सिस्टम लेनदेन तक फैली हुई है। इसका कारण पहले ही ऊपर उल्लेखित किया गया है - एक लंबे लॉक कैप्चर के साथ समस्याएं। यह इस प्रकार है कि अपने स्वयं के सिंक्रनाइज़ेशन तंत्र को लागू करना आवश्यक है, जो कई सिस्टम लेनदेन के शीर्ष पर काम करेगा, क्योंकि DBMS सिंक्रनाइज़ेशन तंत्र केवल एक सिस्टम लेनदेन के भीतर काम करता है। इस समस्या को हल करने के लिए, दो आशावादी ऑफ़लाइन लॉक और निराशावादी ऑफ़लाइन लॉक पैटर्न का वर्णन किया गया है, जो आशावादी और निराशावादी प्रकार के प्रतिस्पर्धी नियंत्रण को लागू करते हैं।

मान लीजिए कि उपयोगकर्ता संपादन फ़ॉर्म खोलता है, तो वह दस्तावेज़ पर कई मिनटों तक काम करता है और परिणाम बचाता है। यह व्यापार लेनदेन का एक विशिष्ट उदाहरण है।

आशावादी प्रतिस्पर्धी नियंत्रण के साथ स्थिति पर विचार करें। यदि संपादन परिणाम को सहेजते समय किसी विरोध का पता चलता है, तो उपयोगकर्ता को बदले हुए डेटा और आगे की कार्रवाई के विकल्प के साथ एक संवाद के साथ सूचित किया जाएगा। ऑप्टिमिस्टिक ऑफ़लाइन लॉक पैटर्न एक परिवर्तन नियंत्रण तंत्र का वर्णन करता है, जो सामान्य स्थिति में, एक संस्करणित डेटा तंत्र पर निर्भर करता है। जब भी कोई परिवर्तन सहेजा जाता है, डेटाबेस में डेटा के संस्करण की तुलना उस संस्करण से की जाती है जिसके आधार पर परिवर्तन किए गए थे। यदि ये संस्करण समान हैं, तो वर्तमान संस्करण बदल जाता है और परिणाम बच जाता है, अन्यथा एक संघर्ष उत्पन्न होता है और इसे या तो कार्रवाई दोहराकर या रद्द करके संसाधित किया जाता है।

 public class DomainObject { private Integer id; private Integer version; private Object data; //   } public class UnitOfWork { // ,   public void update(List<DomainObject> updatedObjects) throws SQLException { PreparedStatement ps = connection.prepareStatement( "update domain_objects set data = ?, version = version + 1 " + "where id = ? and version = ?" ); for (DomainObject domainObject: updatedObjects) { ps.setObject(1, domainObject.getData()); ps.setInt(2, domainObject.getId()); ps.setInt(3, domainObject.getVersion()); if (ps.executeUpdate() == 0) { throw new RuntimeException(" "); } } } }

उपरोक्त कोड अपडेट विधि के कार्यान्वयन को ऊपर वर्णित आशावादी ऑफ़लाइन लॉक पैटर्न के साथ दिखाता है। इस कार्यान्वयन में, परिवर्तित वस्तुओं की सूची को संस्करण सत्यापन के साथ सहेजा जाता है। यदि संस्करण बदल गया है, तो तालिका में एक भी रिकॉर्ड अपडेट नहीं किया जाएगा और इस उदाहरण में एक अपवाद फेंक दिया गया है। यह अपवाद एक संघर्ष से मेल खाता है जिसमें रिकॉर्ड पहले से ही निष्पादन के एक प्रतिस्पर्धी धागे द्वारा अद्यतन किया गया है।
निराशावादी प्रतिस्पर्धी नियंत्रण के मामले में, निराशावादी ऑफ़लाइन लॉक पैटर्न का कार्यान्वयन नीचे प्रस्तुत किया गया है।

 class DomainObject { private Integer id; private Boolean blocked; private Object data; //   } public class UnitOfWork { // ,   public void update(List<DomainObject> updatedObjects) throws SQLException { PreparedStatement updateStatement = connection.prepareStatement( "update domain_objects set data = ?, blocked = false " + "where id = ? and blocked = true" ); for (DomainObject domainObject: updatedObjects) { updateStatement.setObject(1, domainObject.getData()); updateStatement.setInt(2, domainObject.getId()); updateStatement.executeUpdate(); } } public DomainObject get(Integer id) throws SQLException { PreparedStatement updateStatement = connection.prepareStatement( "update domain_objects set blocked = true " + "where id = ? and blocked = false" ); updateStatement.setInt(1, id); if (updateStatement.executeUpdate() == 1) { PreparedStatement selectStatement = connection.prepareStatement( "select * from domain_objects where id = ?" ); selectStatement.setInt(1, id); ResultSet result = selectStatement.executeQuery(); //result    //  DomainObject    result return new DomainObject(); } else { throw new RuntimeException("  "); } } }

प्रस्तुत कोड में, डेटाबेस से डेटा प्राप्त करते समय, अवरोधित फ़ील्ड पर एक लॉक सेट किया जाता है। यदि यह पहले से ही सेट है, तो एक अपवाद फेंक दिया जाता है, अन्यथा परिणाम वापस आ जाता है। इसके अलावा, जब ऑब्जेक्ट को अपडेट किया जाता है, तो लॉक रीसेट हो जाता है। यह कार्यान्वयन लेन-देन अलगाव के सभी स्तरों के साथ काम करेगा। बशर्ते कि ताले को पकड़ने के बाद डेटा सहेजा जाएगा।

प्रस्तुत कार्यान्वयन केवल विवरण का वर्णन करते हैं और वास्तविक अनुप्रयोगों में उपयोग के लिए अभिप्रेत नहीं हैं!

व्यापार स्तर तालाबंदी नीति

अवरोधक नीतियां ऐसे नियम हैं जो डेटा तक समवर्ती पहुंच को नियंत्रित करते हैं। यह पैराग्राफ व्यावसायिक स्तर पर ताले की नीति से संबंधित है, न कि डीबीएमएस और प्लेटफॉर्म सिंक्रोनाइज़ेशन मैकेनिज्म के प्रश्नों के स्तर पर। ध्यान रखें कि लॉक पॉलिसी व्यावसायिक तर्क से संबंधित होनी चाहिए। और आप प्रश्न को बाद के लिए प्रतिस्पर्धी एक्सेस के साथ नहीं छोड़ सकते।उदाहरण के लिए, एक प्रणाली में जहां यह गुंजाइश इंगित करती है कि एक निश्चित दस्तावेज को पूरी तरह से संपादित किया जाना चाहिए, यह आवश्यक है कि व्यावसायिक तर्क के पास इस आवश्यकता का ज्ञान हो। व्यावसायिक क्षेत्र की ऐसी आवश्यकता के कार्यान्वयन के मामले में, केवल सिंक्रनाइज़ेशन तंत्र की मदद से, आवेदन में व्यवसाय स्तर के कार्यान्वयन को कई भागों में विभाजित किया जाएगा, जो बहुत अच्छा नहीं है। सबसे पहले, क्योंकि ऐसी प्रणाली का समर्थन जटिल है, हालांकि अंतर्निहित डीबीएमएस प्रक्रियाओं का उपयोग करके प्रदर्शन का अनुकूलन करने का विकल्प काफी आम है। दूसरे, एक लंबी प्रणाली के लेन-देन के साथ एक समस्या है, अर्थात, आप एक व्यापार लेनदेन के रूप में एक ही समय में एक सिस्टम लेनदेन को खुला रखने की अनुमति नहीं दे सकते। एक व्यापार लेनदेन के लिए जिम्मेदारी का क्षेत्र आवेदन के व्यावसायिक तर्क के साथ निहित है।इसलिए, व्यावसायिक लेन-देन में लॉक पॉलिसी को व्यावसायिक तर्क से अलग नहीं माना जा सकता है।

अतिरिक्त स्रोत

एंटरप्राइज एप्लीकेशन आर्किटेक्चर के पैटर्न (मार्टिन फाउलर, डेविड राइस, मैथ्यू फेममेल, एडवर्ड हीेट, रॉबर्ट मी, रैंडी स्टैफोर्ड)
पोस्टग्रैसीक्यूसी कॉनएरेबिलिटी कंट्रोल कंसीलर
कंट्रोल
आइसोलेशन लेवल

रिलेशनल डेटाबेस के लिए प्रतिस्पर्धी पहुँच