View source for परमाणु प्रतिबद्ध

{{Short description|Operation that applies a set of distinct changes as a single operation}}
[[कंप्यूटर विज्ञान]] के क्षेत्र में, एक एटॉमिक [[कमिट (डेटा प्रबंधन)]] एक ऑपरेशन है जो एकल ऑपरेशन के रूप में विशिष्ट परिवर्तनों के एक सेट को लागू करता है। यदि परिवर्तन लागू होते हैं, तो कहा जाता है कि परमाणु प्रतिबद्धता सफल हुई है। यदि एटॉमिक कमिट पूरा होने से पहले कोई विफलता होती है, तो एटॉमिक कमिट में पूरे किए गए सभी परिवर्तन उलट दिए जाते हैं। यह सुनिश्चित करता है कि सिस्टम हमेशा एक सुसंगत स्थिति में बना रहे। अलगाव की अन्य प्रमुख संपत्ति उनकी प्रकृति से परमाणुता ([[डेटाबेस सिस्टम]]) संचालन के रूप में आती है। अलगाव सुनिश्चित करता है कि एक समय में केवल एक परमाणु प्रतिबद्धता संसाधित की जा सकती है। डेटाबेस सिस्टम और [[ संस्करण नियंत्रण | संस्करण नियंत्रण]] में एटॉमिक कमिट का सबसे साधारण उपयोग है।

परमाणु कमिट के साथ समस्या यह है कि उसे कई सिस्टम्स के बीच समन्वय बनाने की आवश्यकता होती है।<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>

यह उदाहरण खाता 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> अटॉमिसिटी (डेटाबेस सिस्टम) और कंसिस्टेंसी [[संगति (डेटाबेस सिस्टम)|(डेटाबेस सिस्टम)]]। कंसिस्टेंसी तभी प्राप्त होती है जब परमाणु प्रतिबद्धता में प्रत्येक परिवर्तन सुसंगत होता है।

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

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

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

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

सभी नोड्स द्वारा तैयारी संदेश का जवाब देने के बाद <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="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" />
== परमाणु प्रतिबद्ध सम्मेलन ==

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

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

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

== यह भी देखें ==
* दो-चरण प्रतिबद्ध प्रोटोकॉल
* तीन चरण प्रतिबद्ध प्रोटोकॉल
* प्रतिबद्ध (डेटा प्रबंधन)
* [[परमाणु संचालन]]

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



[[Category: Machine Translated Page]]
[[Category:Created On 26/05/2023]]
[[Category:Vigyan Ready]]