2009-05-07 7 views
8

मेरे पास एक एएसपी.NET सी # व्यवसाय वेबपैप है जो आंतरिक रूप से उपयोग किया जाता है। एक मुद्दा जिसे हम विकसित कर रहे हैं, यह है कि मूल डिजाइन समेकन जांच के लिए जिम्मेदार नहीं था - इसलिए अब एकाधिक उपयोगकर्ता एक ही डेटा तक पहुंच रहे हैं और अन्य उपयोगकर्ताओं के परिवर्तनों को ओवरराइट कर रहे हैं। तो मेरा सवाल यह है कि - वेबपैप्स के लिए लोग आमतौर पर निराशावादी या आशावादी समेकन प्रणाली का उपयोग करते हैं? एक दूसरे के ऊपर एक का उपयोग करने की प्राथमिकता क्या है और कुछ डिजाइन विचारों को ध्यान में रखना क्या है?पसंदीदा डेटाबेस/वेबएप कॉन्सुरेंसी डिज़ाइन जब एकाधिक उपयोगकर्ता एक ही डेटा को संपादित कर सकते हैं

मैं वर्तमान में एक आशावादी समेकन जांच की ओर झुक रहा हूं क्योंकि यह अधिक क्षमाशील लगता है, लेकिन मैं कई बदलावों की संभावना के बारे में चिंतित हूं जो एक-दूसरे के विरोधाभास में होंगे।

धन्यवाद!

उत्तर

3

आशावादी लॉकिंग।
निराशावादी लागू करना कठिन है और वेब वातावरण में समस्याएं देगा। लॉक को बंद करने, ब्राउज़र बंद करने के लिए कौन सी कार्रवाई जारी होगी? सत्र को समय पर छोड़ना? इसके बारे में क्या होगा यदि वे अपने परिवर्तनों को बचाते हैं?

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

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

होल्डिंग लेनदेन खुला (जैसा कि @le dorfier द्वारा सुझाया गया है) निराशावादी लॉकिंग के समान है, लेकिन लॉक डेटा की मात्रा एक पंक्ति से अधिक हो सकती है। डिफ़ॉल्ट रूप से पेज स्तर पर अधिकांश आरडीबीएम लॉक।आप निराशावादी लॉकिंग के साथ ही एक ही मुद्दे में भाग लेंगे।

आप अपने प्रश्न में उल्लेख करते हैं कि आप विवादित अपडेट के बारे में चिंतित हैं। लॉकिंग निश्चित रूप से रोक देगा। आशावादी या निराशावादी दोनों, ठीक से कार्यान्वित होने पर ठीक उसी तरह से रोकें।

+0

मुझे टाइमस्टैम्प डेटा प्रकार से बेहतर अंतिम तिथि दिनांक पसंद है, क्योंकि इसमें उपयोगी डेटा है। हमारे पास व्यक्ति को ट्रैक करने के लिए एक LastChgID भी है, दोनों कॉलम प्रदर्शित करने के लिए अच्छे हैं, जहां टाइमस्टैम्प डेटा प्रकार कॉलम प्रदर्शित करने के लिए व्यर्थ है। –

+0

यदि इस प्रकार का डेटा पहले से ही एक आवश्यकता है तो इसका उपयोग करने का कोई कारण नहीं है। मैंने तदनुसार अपना जवाब अपडेट किया है। – pipTheGeek

0

मुझे लगता है कि आप 'खोए गए अपडेट' समस्या का सामना कर रहे हैं।

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

आपको वास्तव में यह देखने की ज़रूरत है कि आपकी स्थिति पर क्या लागू होता है और निर्णय कॉल करता है।

+0

इसके अलावा मैं कभी निराशावादी ताले नहीं रखूंगा जहां यह उपयोगकर्ता संपादन पर इंतजार कर रहा है। –

+0

@ डीजे अच्छा बिंदु, मैं इसका उल्लेख करना भूल गया। – Glen

+0

@Glen ने कहा, "यहां देखने के लिए एक बात यह है कि यदि दिनांक कॉलम के संकल्प के भीतर 2 अपडेट होते हैं तो आपका तर्क असफल हो जाएगा। यह एक बहुत दुर्लभ एज केस है, लेकिन यह अभी भी हो सकता है।" हालांकि, किसी को लॉक मिलेगा (याद रखें कि यह एक लेनदेन में है), दूसरा कोई नहीं करेगा और यह इंतजार करेगा और फिर अपडेट होने का मौका मिलने पर तिथियां अलग होंगी। –

1

यहां एक ही रिकॉर्ड पर काम कर रहे कई लोगों के लिए एक आसान समाधान है।

जब आप डेटा लोड, पिछले बदल तारीख मिलता है, हम अपने टेबल

जब आप सहेजने पर LastChgDate का उपयोग करें (अद्यतन) डेटा जहां खंड में जोड़ें "और LastChgDate = previouslyLoadedLastChgDate"। यदि अद्यतन पर पंक्ति गणना = 0 है, तो त्रुटि त्रुटि जहां "किसी और ने पहले से ही यह डेटा सहेजा है" और रोलबैक सबकुछ, अन्यथा डेटा सहेजा गया है।

मैं आम तौर पर केवल शीर्ष लेखों पर उपरोक्त तर्क करता हूं, न कि विवरण तालिकाओं पर, क्योंकि वे सभी एक लेनदेन में हैं।

+0

यहां देखने के लिए एक बात यह है कि यदि दिनांक कॉलम के संकल्प के भीतर 2 अपडेट होते हैं तो आपका तर्क विफल हो जाएगा। यह एक बहुत ही दुर्लभ किनारा मामला है, लेकिन यह अभी भी हो सकता है। – Glen

+0

@Glen, एक को लॉक मिलेगा (याद रखें कि यह एक लेनदेन में है), दूसरा कोई नहीं करेगा और यह इंतजार करेगा और फिर अपडेट होने का मौका मिलने पर तिथियां अलग होंगी। –

3

मैं ऊपर दिए गए पहले उत्तर से सहमत हूं, हम आशावादी लॉकिंग का उपयोग करने का प्रयास करते हैं जब टकराव का मौका काफी कम होता है। इसे आसानी से LastModifiedDate कॉलम या संस्करण कॉलम में वृद्धि के साथ कार्यान्वित किया जा सकता है। यदि आप टकराव की आवृत्ति के बारे में अनिश्चित हैं, तो कहीं कहीं लॉग इन करें ताकि आप उन पर नजर रख सकें। यदि आपके रिकॉर्ड हमेशा "संपादन" मोड में होते हैं, तो अलग-अलग "दृश्य" और "संपादन" मोड होने से टकराव को कम करने में मदद मिल सकती है (माना जाता है कि संपादन मोड दर्ज करते समय आप डेटा पुनः लोड करते हैं)।

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

कई ऐप्स को दोनों दृष्टिकोणों के संयोजन की आवश्यकता होगी।

संबंधित मुद्दे

 संबंधित मुद्दे