2008-09-11 16 views
12

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

वितरित लेनदेन कैसे काम करते हैं? कुछ एमएस दस्तावेज में मैंने पढ़ा है कि आप किसी भी तरह डेटाबेस और फाइल सिस्टम (अन्य चीजों के साथ) में लेनदेन कर सकते हैं।

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

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

मैंने http://blogs.msdn.com/florinlazar/archive/2004/03/04/84199.aspx पढ़ा है, लेकिन यह केवल स्पष्टीकरण की शुरुआत की तरह लगता है, और चरण 4 को काफी विस्तारित किया जाना चाहिए।

संपादित करें: से मैं क्या http://en.wikipedia.org/wiki/Distributed_transaction पर इकट्ठा होते हैं, यह एक दो चरण से पूरा किया जा सकता प्रतिबद्ध (http://en.wikipedia.org/wiki/Two-phase_commit)। इसे पढ़ने के बाद, मैं अभी भी विधि 100% समझ नहीं रहा हूं, ऐसा लगता है कि चरणों के बीच त्रुटि के लिए बहुत सी जगह है।

+0

त्रुटि * त्रुटि के लिए कमरे का एक बड़ा सौदा है। विशेष रूप से, यह हमेशा काम करने वाली "COMMIT तैयार" पर निर्भर करता है। वास्तविकता अलग है। –

उत्तर

3

के बारे में "चरण 4":

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

यह निश्चित रूप से सभी प्रतिभागियों को उचित इंटरफेस और (त्रुटि मुक्त) कार्यान्वयन प्रदान करने की आवश्यकता है। इंटरफ़ेस थोड़ा इस तरह दिखता है:

public interface ITransactionParticipant { 
    bool WouldCommitWork(); 
    void Commit(); 
    void Rollback(); 
} 

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

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

+3

क्या होता है यदि आपके पास प्रतिभागी ए और बी हैं, ए प्रतिबद्ध हो जाता है और सफलता देता है, तो बी प्रतिबद्ध हो जाता है और विफलता देता है लेकिन पहले ए को वापस घुमाया जा सकता है, नेटवर्क गिर जाता है? एक अन्य मामले नेटवर्क विफलता बी को रोकने से रोक सकती है। – BCS

+0

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

+0

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