डेटाबेस के बाहर लेनदेन को लागू करने के लिए पैटर्न

Question

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

इससे पहले कि मैं अपना ऑब्जेक्ट एसीआईडी ​​इंजन रोलिंग करूँ, क्या ऑब्जेक्ट स्तर पर एसीआईडी ​​अर्थशास्त्र को लागू करने के लिए कोई सामान्य रूप से स्वीकार्य पैटर्न हैं?

अभी तक बेहतर है, क्या कोई मौजूदा पुस्तकालय है जो मैं .NET मंच के लिए उपयोग कर सकता हूं?

संपादित करें: मुझे पता है कि एक ईमेल भेजने को पूर्ववत नहीं किया जा सकता है, लेकिन एसएमटीपी सर्वर से कनेक्ट करने में विफल होने से पूरे लेनदेन को मारने का कारण बनता है। साथ ही, मैं भविष्य के कार्यों के साथ उपयोग के लिए इसे विस्तारित करना चाहता हूं।

Answer 1

पिछली बार मैंने ऐसा कुछ देखा था जो कई साल पहले था। मुझे इसके बारे में कुछ याद है कि यह कमांड पैटर्न का उपयोग कर रहा था और प्रत्येक कमान ऑब्जेक्ट को कतार में संग्रहीत कर रहा था। मुझे लगता है कि यह एक लिफो स्टैक था।

तो यदि "लेनदेन" विफल हुआ, तो इंजन कमांड ऑब्जेक्ट को पॉप करेगा, कमांड को पूर्ववत करें, फिर कमांड ऑब्जेक्ट को नष्ट कर दें। ढेर खाली होने तक दोहराएं। "लेनदेन" सफल होने पर ढेर को मंजूरी दे दी गई।

दुर्भाग्य से, मुझे इससे अधिक याद नहीं है।

CSLA.NET एक समान पूर्ववत स्टैक लागू करता है। कोड के साथ यही एकमात्र उदाहरण है जिसे मैं अपने सिर के ऊपर से सोच सकता हूं।

Answer 2

विंडोज वर्कफ़्लो फाउंडेशन में compensation (समग्र गतिविधि का उपयोग करके) की अवधारणा है जब एसीआईडी ​​अर्थशास्त्र उचित नहीं हो सकता है .. बेशक, इसमें एसीआईडी ​​लेनदेन के लिए भी समर्थन है।

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

Answer 3

जब से तुम नहीं एक ई-मेल अन-भेज सकते हैं, और यह एक फ़ाइल में लिखने का अपेक्षाकृत सस्ती है, मैं सिर्फ उन चीजों उचित क्रम में करना चाहते हैं:

1. कोशिश फ़ाइल में लिखने का/फ़ाइल लिखें। अगर असफल, रोकें, अन्यथा जारी रखें:
2. वेब सेवा पर कॉल करें।यदि असफल हो, तो फ़ाइल को हटाएं और रोकें, अन्यथा जारी रखें:
3. ई-मेल भेजें - ईमेल किसी भी तरह से असीमित है, इसलिए आप वास्तव में कभी नहीं जानते होंगे कि यह भेजा गया था या नहीं, क्योंकि अधिकांश ई-मेल सर्वर पुनः प्रयास करने के लिए सेट हैं यदि कोई त्रुटि होती है तो कुछ दिनों के लिए और आप कभी भी एक पावती वापस नहीं लेते हैं कि ई-मेल तब भी चला गया जब सफल था।

Answer 4

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

कुछ और परिष्कृत के लिए, software transactional memory आज़माएं। वर्तमान भाषाओं में इसे लागू करने के लिए कुछ हद तक बेकार हो सकता है, लेकिन यह काफी शक्तिशाली है और आपको कुछ अतिरिक्त समेकन तकनीक भी दे सकता है।

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

Answer 5

दो विचार:

• Jeffrey Hantin के रूप में उल्लेख है, software transactional memory (एसटीएम) बहुत मीठा होता है। Clojure में इसे कार्यान्वित/उपयोग करने के तरीके पर नज़र डालें; रिच हिकी के videos प्रभावशाली हैं।
• गोफ प्रसिद्धि के Command pattern का एक महत्वपूर्ण पहलू "अस्थिरता" है। इस का एक कार्यान्वयन द्वारा Robert C. Barth

Answer 6

एक विचार सरल (लेकिन फिर भी उपयोगी) प्रस्ताव के लिए नीचे उबाल सकता है 'इंजन' के रूप में JMS उपयोग करने के लिए और आप JMS लेनदेन का उपयोग कर सकते हैं (जो मौजूदा लेनदेन में शामिल हो सकते है जैसे डीबी लेनदेन)। यह एक एसिंक घटना-संचालित आर्किटेक्चर की ओर बढ़ने लगता है जो शायद एक अच्छी बात है जब तक कि हम सरल ऐप्स नहीं बोल रहे हों - इस मामले में आपको शायद सवाल पूछने की आवश्यकता नहीं है।

इसका एक उदाहरण सरल खाता निर्माण होगा। इसके लिए आप डीबी को खाता जानकारी जारी रखना चाहते हैं और उपयोगकर्ता को सक्रियण के लिए एक ईमेल भी भेजना चाहते हैं - लेकिन आप उन्हें स्पष्ट कारणों से उसी लेनदेन में चाहते हैं।

आपको लेनदेन के भीतर ईमेल भेजने का कोड नहीं रखना चाहिए क्योंकि भले ही आप ईमेल भेज सकते हैं - डीबी लेनदेन प्रतिबद्धता किसी कारण या किसी अन्य कारण से विफल हो सकती है। आपको लेनदेन के बाहर ईमेल भेजने को भी नहीं देना चाहिए (प्रतिबद्ध होने के बाद) क्योंकि ईमेल भेजने से अनाथ खाते में असफल हो सकता है।

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

महत्वपूर्ण बात यह है कि - डीबी रिकॉर्ड सुसंगत है और ईमेल अंततः भेजा जाता है।

Answer 7

इसके अलावा, एक प्रायोगिक परियोजना STM .NET हाल ही में रिलीज़ हुई थी। यह परियोजनाएं लेनदेन मेमोरी को सी # में जोड़ती हैं। यह वास्तव में इसका समर्थन करने के लिए सीएलआर को संशोधित करता है।