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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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