ऑब्जेक्ट-स्तरीय लेनदेन प्रबंधन पैटर्न

Question

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

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

समस्या है जब ऊपर की तरह वस्तु बुला चेन होने आता है। लेनदेन शुरू करते समय मुझे पता है कि बी और सी को लेनदेन में भाग लेना चाहिए ताकि मैं उन्हें लेनदेन कोन्टेक्स्ट में जोड़ूं। लेकिन डी के बारे में क्या? मैं नहीं वास्तव में बी और सी

के लिए चारों ओर TransactionContext पारित करने के लिए मैं अपने दृष्टिकोण पर कुछ इनपुट के साथ ही साबित पैटर्न के कुछ संकेत दिए गए (और भी बेहतर) की सराहना करेंगे चाहते हैं।

Answer 1

"मैं नहीं चाहता कि वास्तव में बी और सी के लिए चारों ओर TransactionContext पास करना चाहते हैं"

क्यों नहीं? वे भाग लेते हैं और वे अभी तक अन्य वस्तुओं को प्रतिनिधि देते हैं।

या तो

• हर कोई रजिस्टर की जरूरत है। जिसका मतलब है कि आपको पंजीकरण का प्रतिनिधि होना है। A जानता है कि यह B और C तक पहुंच गया है। जिनमें से प्रत्येक पंजीकरण के लिए और प्रतिनिधि हो सकता है (या नहीं)। यह "RegisterYourselfAndYourDelegatees" विधि के साथ कार्यान्वित करने के लिए अपेक्षाकृत सरल है।

• श्रोता डिज़ाइन पैटर्न त्याग। एक लेनदेन संदर्भ बनाएँ और इसे चारों ओर पास करें। यह पंजीकरण और इंजेक्शन को थोड़ा सरल डिजाइन के साथ बदल देता है। हालांकि, आपको दो संदर्भ उप-वर्गों की आवश्यकता होगी - असली संदर्भ और एक स्टब संदर्भ जो कुछ भी नहीं करता है और लेनदेन संदर्भ के बाहर उपयोग किया जाता है।

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

  पायथन के लिए, यह एक गैर-मुद्दा है; संदर्भ एक वैकल्पिक तर्क है।

Answer 2

(जावा के लिए शुरू में लेकिन वहाँ एक नेट संस्करण भी अब नहीं है)

Spring framework ऐसा कर सकते हैं। विधियों को इस प्रकार चिह्नित किया गया है:

• लेनदेन की आवश्यकता है (अगर कोई पहले से नहीं है तो शुरू होता है);
• एक नया लेनदेन की आवश्यकता है (हमेशा एक नया बनाता है);
• आदि

यह आमतौर पर एनोटेशन के साथ किया जाता है। आप जो वर्णन कर रहे हैं उसकी तरह लगता है।

बाहर चेक Spring's transaction management।

Answer 3

मेरा सुझाव चाहते हैं: Prevayler

Prevayler is an object persistence library for Java. It is an implementation of the 
System Prevalence architectural style, in which data is kept hot in Memory with 
changes journaled for system recovery. 

Prevayler ' s architecture is illustrated in the diagram shown there. Prevayler [1] 
serves as a transactional barrier for the business objects [2] of your application, 
held in Memory. You encapsulate all modifications of your business objects into 
instances of the Transaction interface [3], much like a " command " pattern 
(though different from a command in some details of the pattern). Whenever 
you ask Prevayler to execute a transaction on your business objects [4], Prevayler 
first writes the transaction object to a journal [5] so that data is not lost if your 
system crashes. Prevayler can also write a snapshot of your entire business object 
graph [6] as often as you wish. Prevayler uses the latest snapshot together with 
the journals to automatically recover your business objects from disk [7] on 
application startup by restoring the snapshot and then re-executing every 
transaction that was originally executed after that snapshot was taken. 

बेशक, आप लगातार दुकान को अक्षम करें और केवल इन-स्मृति की दुकान का उपयोग कर सकते हैं।

Answer 4

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

स्कोपगार्ड को हल करने की कोशिश करने वाली समस्या के लिए लागू होने से आप अपने लेनदेन के दायरे को परिभाषित कर सकते हैं, और आसानी से (स्वचालित रूप से इसका अर्थ) आपके लिए यह प्रबंधित कर सकता है कि क्या लेनदेन में ए, बी, सी, डी या कॉलिंग व्यक्ति शामिल हैं तरीकों।