लेनदेन और मल्टीथ्रेडेड डेटाबेस एक्सेस

हाल ही में, मुझे निम्नलिखित कोड निष्पादित करने की आवश्यकता थी (सबसे सरल रूप में प्रस्तुत):

public void Start() { using (var transactionScope = new TransactionScope()) { ... GetOrCreateCompany(someValue); ... transactionScope.Complete(); } } private Company GetOrCreateCompany(string companyName) { var company = _companiesRepository.GetCompany(companyName); //     ;     -  null if (company == null) company = _companiesRepository.Add(companyName); return company; } 

इस कोड को एक बहु-थ्रेडेड वातावरण में निष्पादित किया गया था, जहां प्रत्येक इनपुट स्ट्रीम को स्टार्ट विधि प्राप्त हुई (जिसका अर्थ है कि प्रत्येक स्ट्रीम का अपना लेनदेन था)।

यह प्रतीत होता है सरल कोड में कई बारीकियां हैं, जिन्हें कटौती के तहत चर्चा की जाएगी।



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

नीचे मेरे पहले समाधान का कोड है (भविष्य में, लेनदेन और तालों की बारीकियों को एक उदाहरण के रूप में MySQL का उपयोग करके माना जाएगा):

 public void Start() { using (var transactionScope = new TransactionScope(TransactionScopeOption.Requires, new TransactionOptions() { IsolationLevel = IsolationLevel.Serializable })) { ... GetOrCreateCompany(someValue); ... transactionScope.Complete(); } } private Company GetOrCreateCompany(string companyName) { var company = _companiesRepository.GetCompanyWithWriteLock(companyName); //    SELECT ... FOR UPDATE if (company == null) company = _companiesRepository.Add(companyName); return company; } 

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

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

कंपनी का चयन दो मामलों में हमें अशक्त नहीं करेगा:

1. कंपनी को पिछले लेनदेन के हिस्से के रूप में जोड़ा गया था जो पहले से ही शुरू हो चुका है।
2. कंपनी को वर्तमान लेनदेन के हिस्से के रूप में जोड़ा गया था, और वर्तमान लेनदेन करने के बाद ही अन्य लेनदेन के लिए दृश्यमान हो जाएगा

आइए पहले मामले को अलग से संभालने की कोशिश करें, और ब्लॉक करने से पहले, हम मौजूदा लेनदेन के बाहर एक अनुरोध निष्पादित करेंगे, जो यह जांच करेगा कि क्या पहले से ही किए गए लेनदेन के बीच कोई डेटा खोजा जाना है:

 private Company GetOrCreateCompany(string companyName) { Company company; //    ,  ,       .   -    ,      using (var independentTransactionScope = new TransactionScope(TransactionScopeOption.Suppress)) { company = _companiesRepository.GetCompany(companyName); } //      ,        -     if (company != null) return; //company   null   : 1.      ,        2.      var company = _companiesRepository.GetCompanyWithWriteLock(companyName); if (company == null) //       -       company = _companiesRepository.Add(companyName); } } 

इस अनुकूलन का एक छोटा सा माइनस यह है कि आपको चयन को डुप्लिकेट करना होगा यदि मान वर्तमान लेनदेन के बाहर दिखाई नहीं दे रहे हैं (दूसरे शब्दों में, यदि स्वतंत्र लेन-देन के अंदर अंदर चयन के लिए वापस लौटा है)। लेकिन उत्पादकता में लाभ की पृष्ठभूमि के खिलाफ, आप अपनी आँखें इस अतिरिक्त नमूने को बंद कर सकते हैं।

मैंने यह लेख क्यों लिखा है? मुझे लगता है कि मैं गलत दिशा में चला गया है: समस्या तुच्छ है, और समाधान ... वास्तव में नहीं। इसके अलावा, मुझे इस समस्या के समाधान के उदाहरण नहीं मिले, और यह मुझे और भी अधिक पहेली लगाता है। मुझे उम्मीद है कि टिप्पणीकार वैकल्पिक समाधानों का प्रस्ताव करके या खदान से सहमत होकर स्थिति को स्पष्ट करेंगे।

अद्यतन
व्यक्तिगत पत्राचार में, शदीक्स हैबरमैन (समवर्ती, मेरे सहयोगी) ने एक स्वतंत्र लेनदेन का उपयोग करने के विचार का एक दिलचस्प विकास प्रस्तावित किया - एक स्वतंत्र लेनदेन में न केवल पढ़ने के लिए, बल्कि जोड़ना भी। यह, पहली नज़र में, एक छोटा संशोधन सब कुछ बहुत बदल देता है।

पहला कार्यान्वयन:

 public class TransactionCode { private static readonly object _lockObject = new object(); public void Start() { using (var transactionScope = new TransactionScope()) { ... GetOrCreateCompany(someValue); ... transactionScope.Complete(); } } private Company GetOrCreateCompany(string companyName) { Company company; //,        using (var indepdentTransactionScope = new TransactionScope(TransactionScopeOption.RequiresNew)) { var company = _companiesRepository.GetCompany(companyName); } if (company != null) return; //   ,     //    using (var independentTransactionScope = new TransactionScope(TransactionScopeOption.RequiresNew)) { var company = _companiesRepository.GetCompanyWithWriteLock(companyName); if (company == null) company = _companiesRepository.Add(companyName); independentTransactionScope.Complete(); } } } 

अब हम कंपनी को मुख्य लेनदेन में नहीं जोड़ते हैं, लेकिन इन उद्देश्यों के लिए एक स्वतंत्र लेनदेन का उपयोग करते हैं। यहां मुख्य विशेषता यह है कि चूंकि एक स्वतंत्र लेनदेन में जोड़ शामिल है, जो तुरंत प्रतिबद्ध है, तुरंत जोड़ा गया मूल्य (और मुख्य लेनदेन के बाद प्रतिबद्ध नहीं है, जैसा कि पिछले समाधान में है) अन्य लेनदेन के लिए दृश्यमान हो जाएगा। वैसे, इसमें कोई संदेह नहीं है कि यह दृष्टिकोण अधिक प्रभावी है: मेरे मामले में, प्रदर्शन में वृद्धि 300% थी (और डेटा जितना अधिक गतिशील होगा, छोटे लॉक जीवनकाल के कारण वृद्धि अधिक होगी)।
लेकिन इस समाधान के नुकसान भी हैं:
1. मुख्य दोष यह है कि यदि मुख्य लेन-देन वापस लुढ़का हुआ है, तो स्वतंत्र लेनदेन में जोड़े गए डेटा को वापस नहीं लाया जाएगा (हमने प्रतिबद्ध है)। सामान्य स्थिति में, यह दोष काफी महत्वपूर्ण है ... लेकिन मेरे लिए नहीं: GetOrCreate जैसी विधियों में, मैं अपेक्षाकृत स्वतंत्र डेटा जोड़ता हूं, जो अभी भी जल्दी या बाद में जोड़ा जाएगा: इस लेनदेन में नहीं, इसलिए अगले एक में।
2. मेरे पास TransactionScopeOption.RequiresNew और TransactionScopeOption.Suppress के साथ आसानी से लेन-देन का उपयोग करने के खिलाफ व्यक्तिगत पूर्वाग्रह हैं (मैं अगली पोस्ट में उन्हें कवर करूंगा)।

इस प्रकार, इस तथ्य के बावजूद कि मुझे बाद वाला समाधान अधिक पसंद है, सामान्य स्थिति में यह नहीं कहा जा सकता है कि उनमें से एक दूसरे से बेहतर है - वे अलग हैं।