परमाणु प्रतिबद्ध: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Operation that applies a set of distinct changes as a single operation}} {{Cleanup|date=July 2010}} कंप्यूटर विज्ञान क...")
 
No edit summary
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Short description|Operation that applies a set of distinct changes as a single operation}}
{{Short description|Operation that applies a set of distinct changes as a single operation}}
{{Cleanup|date=July 2010}}
[[कंप्यूटर विज्ञान]] के क्षेत्र में, एक एटॉमिक [[कमिट (डेटा प्रबंधन)]] एक ऑपरेशन है जो एकल ऑपरेशन के रूप में विशिष्ट परिवर्तनों के एक सेट को लागू करता है। यदि परिवर्तन लागू होते हैं, तो कहा जाता है कि परमाणु प्रतिबद्धता सफल हुई है। यदि एटॉमिक कमिट पूरा होने से पहले कोई विफलता होती है, तो एटॉमिक कमिट में पूरे किए गए सभी परिवर्तन उलट दिए जाते हैं। यह सुनिश्चित करता है कि सिस्टम हमेशा एक सुसंगत स्थिति में बना रहे। अलगाव की अन्य प्रमुख संपत्ति उनकी प्रकृति से परमाणुता ([[डेटाबेस सिस्टम]]) संचालन के रूप में आती है। अलगाव सुनिश्चित करता है कि एक समय में केवल एक परमाणु प्रतिबद्धता संसाधित की जा सकती है। डेटाबेस सिस्टम और [[ संस्करण नियंत्रण | संस्करण नियंत्रण]] में एटॉमिक कमिट का सबसे साधारण उपयोग है।
[[कंप्यूटर विज्ञान]] के क्षेत्र में, एक एटॉमिक [[कमिट (डेटा प्रबंधन)]] एक ऑपरेशन है जो एकल ऑपरेशन के रूप में विशिष्ट परिवर्तनों के एक सेट को लागू करता है। यदि परिवर्तन लागू होते हैं, तो कहा जाता है कि परमाणु प्रतिबद्धता सफल हुई है। यदि एटॉमिक कमिट पूरा होने से पहले कोई विफलता होती है, तो एटॉमिक कमिट में पूरे किए गए सभी परिवर्तन उलट दिए जाते हैं। यह सुनिश्चित करता है कि सिस्टम हमेशा एक सुसंगत स्थिति में बना रहे। अलगाव की अन्य प्रमुख संपत्ति उनकी प्रकृति से परमाणुता ([[डेटाबेस सिस्टम]]) संचालन के रूप में आती है। अलगाव सुनिश्चित करता है कि एक समय में केवल एक परमाणु प्रतिबद्धता संसाधित की जाती है। डेटाबेस सिस्टम और [[ संस्करण नियंत्रण ]] में एटॉमिक कमिट का सबसे आम उपयोग है।
 
परमाणु कमिट के साथ समस्या यह है कि उन्हें कई प्रणालियों के बीच समन्वय की आवश्यकता होती है।<ref>{{cite book |last=Bocchi |first=Wischik |title=ए प्रोसेस कैलकुलस ऑफ़ एटॉमिक कमिटमेंट|year=2004}}</ref> चूंकि कंप्यूटर नेटवर्क अविश्वसनीय सेवाएं हैं, इसका मतलब है कि कोई भी एल्गोरिदम सभी प्रणालियों के साथ समन्वय नहीं कर सकता जैसा कि दो जनरलों की समस्या में साबित हुआ है। जैसे-जैसे डेटाबेस अधिक से अधिक वितरित होते जाते हैं, यह समन्वय सही मायने में परमाणु कमिट करने की कठिनाई को बढ़ा देगा।<ref>{{cite book |first1=Hector |last1=Garcia-Molina |first2=Jeff |last2=Ullman |first3=Jennifer |last3=Widom |title=डेटाबेस सिस्टम द कम्प्लीट बुक|url=https://archive.org/details/databasesystemsc0000_2ndedgarc |url-access=registration |pages=[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/1008 1008]–1009 |publisher=Prentice Hall |year=2009|isbn=9780131873254 }}</ref>
 


परमाणु कमिट के साथ समस्या यह है कि उसे कई सिस्टम्स के बीच समन्वय बनाने की आवश्यकता होती है।<ref>{{cite book |last=Bocchi |first=Wischik |title=ए प्रोसेस कैलकुलस ऑफ़ एटॉमिक कमिटमेंट|year=2004}}</ref> चूंकि कंप्यूटर नेटवर्क अविश्वसनीय सेवाएं होती हैं, इसका मतलब है कि कोई भी एल्गोदम सभी सिस्टम्स के साथ समन्वय बनाकर नहीं  रख सकता जैसा कि दो जनरलों की समस्या में साबित हुआ है। जैसे-जैसे डेटाबेस अधिक से अधिक वितरित होते जाते हैं, यह समन्वय सही मायने में परमाणु कमिट करने की कठिनाई को बढ़ा देती है।<ref>{{cite book |first1=Hector |last1=Garcia-Molina |first2=Jeff |last2=Ullman |first3=Jennifer |last3=Widom |title=डेटाबेस सिस्टम द कम्प्लीट बुक|url=https://archive.org/details/databasesystemsc0000_2ndedgarc |url-access=registration |pages=[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/1008 1008]–1009 |publisher=Prentice Hall |year=2009|isbn=9780131873254 }}</ref>
== उपयोग ==
== उपयोग ==
डेटा के बहु-चरणीय अद्यतन के लिए परमाणु प्रतिबद्धता आवश्यक है। इसे दो चेकिंग खातों के बीच धन हस्तांतरण के एक सरल उदाहरण में स्पष्ट रूप से दिखाया जा सकता है।<ref>{{Cite book |first1=Hector |last1=Garcia-Molina |first2=Jeff |last2=Ullman |first3=Jennifer |last3=Widom |title=डेटाबेस सिस्टम द कम्प्लीट बुक|url=https://archive.org/details/databasesystemsc0000_2ndedgarc |url-access=registration |page=[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/299 299] |publisher=Prentice Hall |year=2009|isbn=9780131873254 }}</ref>
डेटा के बहु-चरणीय अद्यतन के लिए परमाणु प्रतिबद्धता आवश्यक है। इसे दो चेकिंग खातों के बीच धन हस्तांतरण के एक सरल उदाहरण में स्पष्ट रूप से दिखाया जा सकता है।<ref>{{Cite book |first1=Hector |last1=Garcia-Molina |first2=Jeff |last2=Ullman |first3=Jennifer |last3=Widom |title=डेटाबेस सिस्टम द कम्प्लीट बुक|url=https://archive.org/details/databasesystemsc0000_2ndedgarc |url-access=registration |page=[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/299 299] |publisher=Prentice Hall |year=2009|isbn=9780131873254 }}</ref>
यह उदाहरण खाता X से Y में 100 डॉलर स्थानांतरित करने के लिए लेनदेन के दौरान खाता Y की शेष राशि की जांच करने के लिए एक लेनदेन से जटिल है। शुरू करने के लिए, पहले 100 डॉलर खाते X से हटा दिए जाते हैं। दूसरा, खाते Y में 100 डॉलर जोड़े जाते हैं। यदि संपूर्ण ऑपरेशन एक परमाणु प्रतिबद्धता के रूप में पूरा नहीं हुआ है, तो कई समस्याएं हो सकती हैं। यदि ऑपरेशन के बीच में सिस्टम विफल हो जाता है, एक्स से पैसा निकालने के बाद और वाई में जोड़ने से पहले, तो 100 डॉलर गायब हो गए हैं। एक अन्य मुद्दा यह है कि यदि 100 डॉलर जोड़ने से पहले वाई की शेष राशि की जांच की जाती है, तो वाई के लिए गलत शेष राशि की सूचना दी जाएगी।


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


== डाटाबेस सिस्टम ==
== डाटाबेस सिस्टम ==
डेटाबेस सिस्टम में एटॉमिक कमिट [[ACID]] के दो प्रमुख गुणों को पूरा करता है,<ref>{{cite book |last=Elmasri |first=Ramez |title=Fundamentals of Database Systems 5th Edition |page=620 |publisher=Addison Wesley |year=2006}}</ref> परमाणुता (डेटाबेस सिस्टम) और [[संगति (डेटाबेस सिस्टम)]]। संगति तभी प्राप्त होती है जब परमाणु प्रतिबद्धता में प्रत्येक परिवर्तन सुसंगत होता है।
डेटाबेस सिस्टम में एटॉमिक कमिट [[ACID]] के दों प्रमुख गुणों को पूरा करता है,<ref>{{cite book |last=Elmasri |first=Ramez |title=Fundamentals of Database Systems 5th Edition |page=620 |publisher=Addison Wesley |year=2006}}</ref> अटॉमिसिटी (डेटाबेस सिस्टम) और कंसिस्टेंसी [[संगति (डेटाबेस सिस्टम)|(डेटाबेस सिस्टम)]]। कंसिस्टेंसी तभी प्राप्त होती है जब परमाणु प्रतिबद्धता में प्रत्येक परिवर्तन सुसंगत होता है।


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


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


<u>वोटिंग</u> चरण के दौरान प्रत्येक नोड एटॉमिक कमिट में परिवर्तनों को अपनी डिस्क पर लिखता है। नोड्स तब समन्वयक को अपनी स्थिति की रिपोर्ट करते हैं। यदि कोई नोड समन्वयक को रिपोर्ट नहीं करता है या उनका स्थिति संदेश खो जाता है तो समन्वयक मान लेता है कि नोड का लेखन विफल हो गया है। एक बार जब सभी नोड्स समन्वयक को रिपोर्ट कर देते हैं तो दूसरा चरण शुरू हो जाता है।
<u>वोटिंग</u> चरण के दौरान प्रत्येक नोड एटॉमिक कमिट में परिवर्तनों को अपनी डिस्क पर लिखता है। नोड्स तब समन्वयक को अपनी स्थिति की रिपोर्ट करते हैं। यदि कोई नोड समन्वयक को रिपोर्ट नहीं करता है या उनका स्थिति संदेश खो जाता है तो समन्वयक मान लेता है कि नोड का लेखन विफल हो गया है। एक बार जब सभी नोड्स समन्वयक को रिपोर्ट कर देते हैं तो दूसरा चरण प्रारम्भ हो जाता है।


<u>प्रतिबद्ध</u> चरण के दौरान समन्वयक प्रत्येक नोड को उनके व्यक्तिगत लॉग में रिकॉर्ड करने के लिए एक प्रतिबद्ध संदेश भेजता है। जब तक इस संदेश को नोड के लॉग में नहीं जोड़ा जाता, तब तक किए गए किसी भी परिवर्तन को अपूर्ण के रूप में रिकॉर्ड किया जाएगा। यदि किसी भी नोड ने विफलता की सूचना दी तो समन्वयक इसके बजाय एक रोलबैक संदेश भेजेगा। यह नोड्स द्वारा डिस्क में लिखे गए किसी भी परिवर्तन को हटा देगा।<ref>{{cite book |last=Elmasri |first=Ramez |title=Fundamentals of Database Systems 5th Edition |page=688 |publisher=Addison Wesley |year=2006}}</ref><ref>{{cite book |first1=Philip A. |last1=Bernstein |first2=Vassos |last2=Hadzilacos |first3=Nathan |last3=Goodman |title=डाटाबेस सिस्टम में संगामिति नियंत्रण और पुनर्प्राप्ति|chapter=Chapter 7 |publisher=Addison Wesley Publishing Company |year=1987 |url=http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx}}</ref>
<u>प्रतिबद्ध</u> (कमिट) चरण के दौरान समन्वयक प्रत्येक नोड को उनके व्यक्तिगत लॉग में रिकॉर्ड करने के लिए प्रतिबद्ध संदेश भेजता है। जब तक इस संदेश को नोड के लॉग में नहीं जोड़ा जाता, तब तक किए गए किसी भी परिवर्तन को अपूर्ण के रूप में रिकॉर्ड किया जाता है। यदि किसी भी नोड ने विफलता की सूचना दी तो समन्वयक इसके बजाय एक रोलबैक संदेश भेजता है। यह नोड्स द्वारा डिस्क में लिखे गए किसी भी परिवर्तन को हटा देता है।<ref>{{cite book |last=Elmasri |first=Ramez |title=Fundamentals of Database Systems 5th Edition |page=688 |publisher=Addison Wesley |year=2006}}</ref><ref>{{cite book |first1=Philip A. |last1=Bernstein |first2=Vassos |last2=Hadzilacos |first3=Nathan |last3=Goodman |title=डाटाबेस सिस्टम में संगामिति नियंत्रण और पुनर्प्राप्ति|chapter=Chapter 7 |publisher=Addison Wesley Publishing Company |year=1987 |url=http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx}}</ref>
तीन चरण प्रतिबद्ध प्रोटोकॉल दो चरण प्रतिबद्ध प्रोटोकॉल के साथ मुख्य समस्या को दूर करने का प्रयास करता है, जो तब होता है जब एक समन्वयक और दूसरा नोड प्रतिबद्ध चरण के दौरान एक ही समय में विफल हो जाता है और न ही यह बता सकता है कि क्या कार्रवाई होनी चाहिए। इस समस्या को हल करने के लिए प्रोटोकॉल में एक तीसरा चरण जोड़ा गया है। <u>प्रतिबद्ध होने की तैयारी</u> चरण <u>वोटिंग</u> चरण के बाद और <u>प्रतिबद्ध</u> चरण से पहले होता है।


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


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


सभी नोड्स द्वारा तैयारी संदेश का जवाब देने के बाद <u>कमिट</u> चरण शुरू होता है। इस चरण में समन्वयक एक भेजता है
वोटिंग चरण में प्रत्येक नोड से सफलता संदेश प्राप्त होने पर <u>प्रतिबद्धता की तैयारी</u> चरण प्रारम्भ होता है। इस चरण के दौरान समन्वयक प्रत्येक नोड को एक तैयारी संदेश भेजता है। प्रत्येक नोड को तैयार संदेश को स्वीकार करना चाहिए और उत्तर देना चाहिए। यदि कोई उत्तर छूट जाता है या कोई नोड वापस आ जाता है कि वे तैयार नहीं हैं तो समन्वयक एक निरस्त संदेश भेजता है। कोई भी नोड जो समय समाप्त होने से पहले तैयार संदेश प्राप्त नहीं करता है, कमिट को रद्द कर देता है।
प्रत्येक नोड को संदेश भेजें। जब प्रत्येक नोड को यह संदेश प्राप्त होता है तो वह वास्तविक कमिट करता है। यदि संदेश खो जाने के कारण प्रतिबद्ध संदेश नोड तक नहीं पहुंचता है या समन्वयक विफल हो जाता है, तो समय समाप्त होने पर वे प्रतिबद्ध प्रदर्शन करेंगे। यदि समन्वयक पुनर्प्राप्ति पर विफल रहता है तो यह प्रत्येक नोड को एक प्रतिबद्ध संदेश भेजेगा।<ref>{{cite book |first=Srinivas R. |last=Gaddam |title=तीन-चरण प्रतिबद्ध प्रोटोकॉल|url=http://ei.cs.vt.edu/~cs5204/fall99/distributedDBMS/sreenu/3pc.html}}</ref>


सभी नोड्स द्वारा तैयारी संदेश का जवाब देने के बाद <u>कमिट</u> चरण प्रारम्भ होता है। इस चरण में समन्वयक एक प्रत्येक नोड को <u>कमिट संदेश</u> भेजता हैl जब प्रत्येक नोड को यह संदेश प्राप्त होता है तो वह वास्तविक कमिट करता है। यदि संदेश खो जाने के कारण प्रतिबद्ध संदेश नोड तक नहीं पहुंचता है या समन्वयक विफल हो जाता है, तो समय समाप्त होने पर वे प्रतिबद्ध प्रदर्शन करेंगे। यदि समन्वयक पुनर्प्राप्ति पर विफल रहता है तो यह प्रत्येक नोड को एक प्रतिबद्ध संदेश भेजता है।<ref>{{cite book |first=Srinivas R. |last=Gaddam |title=तीन-चरण प्रतिबद्ध प्रोटोकॉल|url=http://ei.cs.vt.edu/~cs5204/fall99/distributedDBMS/sreenu/3pc.html}}</ref>
== [[संशोधन नियंत्रण]] ==
परमाणु कमिट संशोधन नियंत्रण की एक सामान्य विशेषता है, और रिपॉजिटरी में एक सुसंगत स्थिति बनाए रखने के लिए महत्वपूर्ण है।<ref name="levenberg">{{cite web |last1=Levenberg |first1=Rachel Potvin, Josh |title=Google एक ही रिपॉजिटरी में अरबों लाइन ऑफ़ कोड क्यों रखता है|url=https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext |website=Communications of the ACM |accessdate=20 July 2018|date=July 2016}}</ref> अधिकांश संस्करण नियंत्रण सॉफ़्टवेयर विफल होने वाली प्रतिबद्धता के किसी भी भाग को लागू नहीं करता है। उल्लेखनीय अपवाद हैं समवर्ती संस्करण सिस्टम, [[माइक्रोसॉफ्ट विजुअल सोर्ससेफ]] और [[आईबीएम वाजिब ClearCase|आईबीएम रैशनल क्लियरकेस]] (जब यूसीएम मोड में) है।<ref>{{cite book |last1=Smart |first1=John Ferguson |title=जावा पावर टूल्स|date=2008 |publisher="O'Reilly Media, Inc." |isbn=9781491954546 |page=301 |url=https://books.google.com/books?id=kE0UDQAAQBAJ&q=visual+sourcesafe+atomic+commit&pg=PA301 |accessdate=26 July 2018 |language=en}}</ref>


== [[संशोधन नियंत्रण]] ==
परमाणु कमिट संशोधन नियंत्रण की एक सामान्य विशेषता है, और रिपॉजिटरी में एक सुसंगत स्थिति बनाए रखने के लिए महत्वपूर्ण है।<ref name="levenberg">{{cite web |last1=Levenberg |first1=Rachel Potvin, Josh |title=Google एक ही रिपॉजिटरी में अरबों लाइन ऑफ़ कोड क्यों रखता है|url=https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext |website=Communications of the ACM |accessdate=20 July 2018|date=July 2016}}</ref> अधिकांश संस्करण नियंत्रण सॉफ़्टवेयर विफल होने वाली प्रतिबद्धता के किसी भी भाग को लागू नहीं करेगा। उल्लेखनीय अपवाद हैं समवर्ती संस्करण सिस्टम, [[माइक्रोसॉफ्ट विजुअल सोर्ससेफ]] और [[आईबीएम वाजिब ClearCase]] (जब यूसीएम मोड में)।<ref>{{cite book |last1=Smart |first1=John Ferguson |title=जावा पावर टूल्स|date=2008 |publisher="O'Reilly Media, Inc." |isbn=9781491954546 |page=301 |url=https://books.google.com/books?id=kE0UDQAAQBAJ&q=visual+sourcesafe+atomic+commit&pg=PA301 |accessdate=26 July 2018 |language=en}}</ref>
उदाहरण के लिए, यदि संस्करण नियंत्रण सॉफ़्टवेयर को एक संपादन विरोध का सामना करना पड़ता है जिसे स्वचालित रूप से हल नहीं किया जा सकता है, तो परिवर्तन का कोई हिस्सा मर्ज नहीं किया जाता है। इसके बजाय, डेवलपर को या तो अपने परिवर्तनों को वापस लाने या संघर्ष को मैन्युअल रूप से हल करने का अवसर दिया जाता है।
उदाहरण के लिए, यदि संस्करण नियंत्रण सॉफ़्टवेयर को एक संपादन विरोध का सामना करना पड़ता है जिसे स्वचालित रूप से हल नहीं किया जा सकता है, तो परिवर्तन का कोई हिस्सा मर्ज नहीं किया जाता है। इसके बजाय, डेवलपर को या तो अपने परिवर्तनों को वापस लाने या संघर्ष को मैन्युअल रूप से हल करने का अवसर दिया जाता है।


यह पूरी परियोजना को आंशिक रूप से लागू परिवर्तन सेट के कारण टूटी हुई स्थिति में प्रवेश करने से रोकता है, जहां एक कमिट से एक फ़ाइल सफलतापूर्वक सबमिट की जाती है, लेकिन निर्भर परिवर्तन वाली दूसरी फ़ाइल विफल हो जाती है।<ref name="versperman">{{cite book |last1=Vesperman |first1=Jennifer |title=आवश्यक सीवीएस।|date=2009 |publisher=O'Reilly Media, Inc. |location=Sebastopol |isbn=9780596551407 |page=7 |edition=2nd |url=https://books.google.com/books?id=nIMNLXCBjn0C&q=atomic+commit+cvs&pg=PA7|quote=A feature that CVS doesn't have, and that many teams like, is atomic commits. This feature ensures that while one person is committing changes to the repository, no one else can. Thus, each commit is a separate process, and the repository is never in a state where it has mismatched files.}}</ref>
यह पूरी परियोजना को आंशिक रूप से लागू परिवर्तन सेट के कारण टूटी हुई स्थिति में प्रवेश करने से रोकता है, जहां एक कमिट से एक फ़ाइल सफलतापूर्वक सबमिट की जाती है, लेकिन निर्भर परिवर्तन वाली दूसरी फ़ाइल विफल हो जाती है।<ref name="versperman">{{cite book |last1=Vesperman |first1=Jennifer |title=आवश्यक सीवीएस।|date=2009 |publisher=O'Reilly Media, Inc. |location=Sebastopol |isbn=9780596551407 |page=7 |edition=2nd |url=https://books.google.com/books?id=nIMNLXCBjn0C&q=atomic+commit+cvs&pg=PA7|quote=A feature that CVS doesn't have, and that many teams like, is atomic commits. This feature ensures that while one person is committing changes to the repository, no one else can. Thus, each commit is a separate process, and the repository is never in a state where it has mismatched files.}}</ref>
एटॉमिक कमिट एक ही ऑपरेशन में वर्जन कंट्रोल सॉफ्टवेयर का उपयोग करके एक [[ monorepo ]] के रूप में ज्ञात वर्जन कंट्रोल सॉफ्टवेयर डेवलपमेंट स्ट्रैटेजी का उपयोग करके एक साथ कई प्रोजेक्ट्स में बदलाव करने की क्षमता को भी संदर्भित कर सकता है।<ref name="levenberg" />


एटॉमिक कमिट एक ही ऑपरेशन में वर्जन कंट्रोल सॉफ्टवेयर का उपयोग करके एक[[ monorepo | मोनोरेपो]] के रूप में ज्ञात वर्जन कंट्रोल सॉफ्टवेयर डेवलपमेंट स्ट्रैटेजी का उपयोग करके एक साथ कई प्रोजेक्ट्स में बदलाव करने की क्षमता को भी संदर्भित कर सकता है।<ref name="levenberg" />
== परमाणु प्रतिबद्ध सम्मेलन ==
== परमाणु प्रतिबद्ध सम्मेलन ==


{{Merge to|Changeset|date=November 2022|section=yes|discussion=Talk:Changeset#Add_section_about_changeset_conventions}}
एक संशोधन नियंत्रण प्रणाली का उपयोग करते समय एक साधारण सा  समझौता यह होता है की छोटे काम का उपयोग किया जाये। इन्हें कभी-कभी परमाणु कमिट के रूप में संदर्भित किया जाता है क्योंकि वे (आदर्श रूप से) सिस्टम के केवल एक पहलू को प्रभावित करते हैं। ये परमाणु कमिट अधिक समझ की अनुमति देते हैं, परिवर्तनों को वापस लाने के लिए कम प्रयास और बग पहचानना आसान कर देता हैं।<ref>{{cite web |publisher=Apache |title=तोड़फोड़ की सर्वोत्तम प्रथाएँ|url=http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html}}</ref>


एक संशोधन नियंत्रण प्रणाली का उपयोग करते समय एक आम सम्मेलन छोटे काम का उपयोग करना है। इन्हें कभी-कभी परमाणु कमिट के रूप में संदर्भित किया जाता है क्योंकि वे (आदर्श रूप से) सिस्टम के केवल एक पहलू को प्रभावित करते हैं। ये परमाणु कमिट अधिक समझ, परिवर्तनों को वापस लाने के लिए कम प्रयास, आसान बग पहचान की अनुमति देते हैं।<ref>{{cite web |publisher=Apache |title=तोड़फोड़ की सर्वोत्तम प्रथाएँ|url=http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html}}</ref>
कमिट के छोटे आकार और केंद्रित प्रकृति से अधिक समझ आती है। यह समझना बहुत आसान है कि क्या बदला है और परिवर्तनों के पीछे क्या कारण है यदि कोई केवल एक प्रकार के परिवर्तन की तलाश कर रहा है। स्रोत कोड में प्रारूप परिवर्तन करते समय यह विशेष रूप से महत्वपूर्ण हो जाता है। यदि प्रारूप और कार्यात्मक परिवर्तन संयुक्त होते हैं तो उपयोगी परिवर्तनों की पहचान करना बहुत कठिन हो जाता है। कल्पना करें कि यदि फ़ाइल में रिक्ति को टैब का उपयोग करके तीन स्थानों में बदल दिया जाता है, तो फ़ाइल में प्रत्येक टैब परिवर्तित होने के रूप में दिखाई देगा। यह महत्वपूर्ण हो जाता है यदि कुछ कार्यात्मक परिवर्तन भी किए जाते हैं क्योंकि समीक्षक कार्यात्मक परिवर्तन नहीं देख सकता है।<ref>{{cite book |first=Boisvert  |last=Barney |title=परमाणु संस्करण नियंत्रण के लिए प्रतिबद्ध है|url=http://www.barneyb.com/barneyblog/2006/01/27/atomic-commits-to-version-control/}}</ref><ref>{{cite web |publisher=Conifer Systems |title=छोटी प्रतिबद्धताओं के लाभ|url=http://www.conifersystems.com/2008/11/05/the-benefits-of-small-commits/}}</ref>
कमिट के छोटे आकार और केंद्रित प्रकृति से अधिक समझ आती है। यह समझना बहुत आसान है कि क्या बदला है और परिवर्तनों के पीछे क्या कारण है यदि कोई केवल एक प्रकार के परिवर्तन की तलाश कर रहा है। स्रोत कोड में प्रारूप परिवर्तन करते समय यह विशेष रूप से महत्वपूर्ण हो जाता है। यदि प्रारूप और कार्यात्मक परिवर्तन संयुक्त होते हैं तो उपयोगी परिवर्तनों की पहचान करना बहुत कठिन हो जाता है। कल्पना करें कि यदि फ़ाइल में रिक्ति को टैब का उपयोग करके तीन स्थानों में बदल दिया जाता है, तो फ़ाइल में प्रत्येक टैब परिवर्तित होने के रूप में दिखाई देगा। यह महत्वपूर्ण हो जाता है यदि कुछ कार्यात्मक परिवर्तन भी किए जाते हैं क्योंकि समीक्षक कार्यात्मक परिवर्तन नहीं देख सकता है।<ref>{{cite book |first=Boisvert  |last=Barney |title=परमाणु संस्करण नियंत्रण के लिए प्रतिबद्ध है|url=http://www.barneyb.com/barneyblog/2006/01/27/atomic-commits-to-version-control/}}</ref><ref>{{cite web |publisher=Conifer Systems |title=छोटी प्रतिबद्धताओं के लाभ|url=http://www.conifersystems.com/2008/11/05/the-benefits-of-small-commits/}}</ref>
यदि केवल एटॉमिक कमिट किए जाते हैं तो ऐसे कमिट होते हैं जो त्रुटियों को पहचानना बहुत आसान हो जाते हैं। यह देखने के लिए कि क्या यह त्रुटि का कारण था, प्रत्येक प्रतिबद्धता को देखने की आवश्यकता नहीं है, केवल उस कार्यक्षमता से निपटने वाले कार्यों की जांच की जानी चाहिए। यदि त्रुटि को वापस लाना है, तो परमाणु कमिट फिर से काम को बहुत आसान बना देता है। अपमानजनक संशोधन के लिए [[प्रत्यावर्तन (सॉफ्टवेयर विकास)]] करने के बजाय और बाद में किसी भी परिवर्तन को एकीकृत करने से पहले परिवर्तनों को मैन्युअल रूप से हटा दें; डेवलपर पहचान की गई प्रतिबद्धता में किसी भी बदलाव को आसानी से वापस कर सकता है। यह एक डेवलपर के जोखिम को भी कम करता है जो एक ही कमिट में हुए असंबद्ध परिवर्तनों को गलती से हटा देता है।
यदि केवल एटॉमिक कमिट किए जाते हैं तो ऐसे कमिट होते हैं जो त्रुटियों को पहचानना बहुत आसान हो जाते हैं। यह देखने के लिए कि क्या यह त्रुटि का कारण था, प्रत्येक प्रतिबद्धता को देखने की आवश्यकता नहीं है, केवल उस कार्यक्षमता से निपटने वाले कार्यों की जांच की जानी चाहिए। यदि त्रुटि को वापस लाना है, तो परमाणु कमिट फिर से काम को बहुत आसान बना देता है। अपमानजनक संशोधन के लिए [[प्रत्यावर्तन (सॉफ्टवेयर विकास)]] करने के बजाय और बाद में किसी भी परिवर्तन को एकीकृत करने से पहले परिवर्तनों को मैन्युअल रूप से हटा दें; डेवलपर पहचान की गई प्रतिबद्धता में किसी भी बदलाव को आसानी से वापस कर सकता है। यह एक डेवलपर के जोखिम को भी कम करता है जो एक ही कमिट में हुए असंबद्ध परिवर्तनों को गलती से हटा देता है।


Line 58: Line 54:
==संदर्भ==
==संदर्भ==
{{Reflist|2}}
{{Reflist|2}}
[[Category: लेनदेन प्रक्रिया]] [[Category: संस्करण नियंत्रण प्रणाली]] [[Category: वितरित कंप्यूटिंग समस्याएं]]


[[Category: Machine Translated Page]]
[[Category:CS1 English-language sources (en)]]
[[Category:Created On 26/05/2023]]
[[Category:Created On 26/05/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:लेनदेन प्रक्रिया]]
[[Category:वितरित कंप्यूटिंग समस्याएं]]
[[Category:संस्करण नियंत्रण प्रणाली]]

Latest revision as of 08:54, 15 June 2023

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

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

उपयोग

डेटा के बहु-चरणीय अद्यतन के लिए परमाणु प्रतिबद्धता आवश्यक है। इसे दो चेकिंग खातों के बीच धन हस्तांतरण के एक सरल उदाहरण में स्पष्ट रूप से दिखाया जा सकता है।[3]

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

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

डाटाबेस सिस्टम

डेटाबेस सिस्टम में एटॉमिक कमिट ACID के दों प्रमुख गुणों को पूरा करता है,[4] अटॉमिसिटी (डेटाबेस सिस्टम) और कंसिस्टेंसी (डेटाबेस सिस्टम)। कंसिस्टेंसी तभी प्राप्त होती है जब परमाणु प्रतिबद्धता में प्रत्येक परिवर्तन सुसंगत होता है।

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

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

वोटिंग चरण के दौरान प्रत्येक नोड एटॉमिक कमिट में परिवर्तनों को अपनी डिस्क पर लिखता है। नोड्स तब समन्वयक को अपनी स्थिति की रिपोर्ट करते हैं। यदि कोई नोड समन्वयक को रिपोर्ट नहीं करता है या उनका स्थिति संदेश खो जाता है तो समन्वयक मान लेता है कि नोड का लेखन विफल हो गया है। एक बार जब सभी नोड्स समन्वयक को रिपोर्ट कर देते हैं तो दूसरा चरण प्रारम्भ हो जाता है।

प्रतिबद्ध (कमिट) चरण के दौरान समन्वयक प्रत्येक नोड को उनके व्यक्तिगत लॉग में रिकॉर्ड करने के लिए प्रतिबद्ध संदेश भेजता है। जब तक इस संदेश को नोड के लॉग में नहीं जोड़ा जाता, तब तक किए गए किसी भी परिवर्तन को अपूर्ण के रूप में रिकॉर्ड किया जाता है। यदि किसी भी नोड ने विफलता की सूचना दी तो समन्वयक इसके बजाय एक रोलबैक संदेश भेजता है। यह नोड्स द्वारा डिस्क में लिखे गए किसी भी परिवर्तन को हटा देता है।[5][6]

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

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

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

सभी नोड्स द्वारा तैयारी संदेश का जवाब देने के बाद कमिट चरण प्रारम्भ होता है। इस चरण में समन्वयक एक प्रत्येक नोड को कमिट संदेश भेजता हैl जब प्रत्येक नोड को यह संदेश प्राप्त होता है तो वह वास्तविक कमिट करता है। यदि संदेश खो जाने के कारण प्रतिबद्ध संदेश नोड तक नहीं पहुंचता है या समन्वयक विफल हो जाता है, तो समय समाप्त होने पर वे प्रतिबद्ध प्रदर्शन करेंगे। यदि समन्वयक पुनर्प्राप्ति पर विफल रहता है तो यह प्रत्येक नोड को एक प्रतिबद्ध संदेश भेजता है।[7]

संशोधन नियंत्रण

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

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

यह पूरी परियोजना को आंशिक रूप से लागू परिवर्तन सेट के कारण टूटी हुई स्थिति में प्रवेश करने से रोकता है, जहां एक कमिट से एक फ़ाइल सफलतापूर्वक सबमिट की जाती है, लेकिन निर्भर परिवर्तन वाली दूसरी फ़ाइल विफल हो जाती है।[10]

एटॉमिक कमिट एक ही ऑपरेशन में वर्जन कंट्रोल सॉफ्टवेयर का उपयोग करके एक मोनोरेपो के रूप में ज्ञात वर्जन कंट्रोल सॉफ्टवेयर डेवलपमेंट स्ट्रैटेजी का उपयोग करके एक साथ कई प्रोजेक्ट्स में बदलाव करने की क्षमता को भी संदर्भित कर सकता है।[8]

परमाणु प्रतिबद्ध सम्मेलन

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

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

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

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

यह भी देखें

  • दो-चरण प्रतिबद्ध प्रोटोकॉल
  • तीन चरण प्रतिबद्ध प्रोटोकॉल
  • प्रतिबद्ध (डेटा प्रबंधन)
  • परमाणु संचालन

संदर्भ

  1. ↑ Bocchi, Wischik (2004). ए प्रोसेस कैलकुलस ऑफ़ एटॉमिक कमिटमेंट.
  2. ↑ Garcia-Molina, Hector; Ullman, Jeff; Widom, Jennifer (2009). डेटाबेस सिस्टम द कम्प्लीट बुक. Prentice Hall. pp. 1008–1009. ISBN 9780131873254.
  3. ↑ Garcia-Molina, Hector; Ullman, Jeff; Widom, Jennifer (2009). डेटाबेस सिस्टम द कम्प्लीट बुक. Prentice Hall. p. 299. ISBN 9780131873254.
  4. ↑ Elmasri, Ramez (2006). Fundamentals of Database Systems 5th Edition. Addison Wesley. p. 620.
  5. ↑ Elmasri, Ramez (2006). Fundamentals of Database Systems 5th Edition. Addison Wesley. p. 688.
  6. ↑ Bernstein, Philip A.; Hadzilacos, Vassos; Goodman, Nathan (1987). "Chapter 7". डाटाबेस सिस्टम में संगामिति नियंत्रण और पुनर्प्राप्ति. Addison Wesley Publishing Company.
  7. ↑ Gaddam, Srinivas R. तीन-चरण प्रतिबद्ध प्रोटोकॉल.
  8. ↑ 8.0 8.1 Levenberg, Rachel Potvin, Josh (July 2016). "Google एक ही रिपॉजिटरी में अरबों लाइन ऑफ़ कोड क्यों रखता है". Communications of the ACM. Retrieved 20 July 2018.{{cite web}}: CS1 maint: multiple names: authors list (link)
  9. ↑ Smart, John Ferguson (2008). जावा पावर टूल्स (in English). "O'Reilly Media, Inc.". p. 301. ISBN 9781491954546. Retrieved 26 July 2018.
  10. ↑ Vesperman, Jennifer (2009). आवश्यक सीवीएस। (2nd ed.). Sebastopol: O'Reilly Media, Inc. p. 7. ISBN 9780596551407. A feature that CVS doesn't have, and that many teams like, is atomic commits. This feature ensures that while one person is committing changes to the repository, no one else can. Thus, each commit is a separate process, and the repository is never in a state where it has mismatched files.
  11. ↑ "तोड़फोड़ की सर्वोत्तम प्रथाएँ". Apache.
  12. ↑ Barney, Boisvert. परमाणु संस्करण नियंत्रण के लिए प्रतिबद्ध है.
  13. ↑ "छोटी प्रतिबद्धताओं के लाभ". Conifer Systems.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=परमाणु_प्रतिबद्ध&oldid=187673’