संस्करण का मुख्य उद्देश्य आशावादी लॉकिंग है।
सक्षम होने पर, जब भी कोई दस्तावेज़ अपडेट किया जाता है, तो संस्करण मान परमाणु रूप से बढ़ जाता है।
यह आपके एप्लिकेशन कोड को यह जांचने की अनुमति देता है कि क्या परिवर्तन एक लाने के बीच किए गए हैं (उदाहरण के लिए संस्करण कुंजी 42 लाना) और एक परिणामी अपडेट (संस्करण मान अभी भी 42 है सुनिश्चित करना)। यदि संस्करण कुंजी का एक अलग मान है (उदाहरण के लिए 43 क्योंकि एक दस्तावेज़ में अद्यतन किया गया है), आपका एप्लिकेशन कोड समवर्ती संशोधन को संभाल सकता है।
निराशावादी लॉकिंग के बजाय रिलेशनल डेटाबेस में अक्सर उसी अवधारणा का उपयोग किया जाता है जो भयानक प्रदर्शन ला सकता है। सभी सभ्य ओआरएम ऐसी सुविधा प्रदान करते हैं। उदाहरण के लिए इसे ऑब्जेक्टडीबी दस्तावेज़ में अच्छी तरह से वर्णित किया गया है . यह जावा में लागू किया गया एक ऑब्जेक्ट डेटाबेस है लेकिन एक ही अवधारणा लागू होती है।
ब्लॉग पोस्ट Behlül की टिप्पणी में लिंक एक ठोस उदाहरण के साथ आशावादी लॉकिंग उपयोगिता को प्रदर्शित करता है, लेकिन केवल सरणियों में परिवर्तन के लिए, नीचे देखें।
इसके विपरीत, यहाँ एक साधारण मामला है जहाँ यह बेकार है:एक उपयोगकर्ता प्रोफ़ाइल जिसे उसके स्वामी द्वारा स्वयं संपादित किया जा सकता है। यहां आप आशावादी लॉकिंग से छुटकारा पा सकते हैं और मान सकते हैं कि अंतिम संपादन हमेशा जीतता है।
तो, केवल आप ही जानते हैं कि आपके आवेदन को आशावादी लॉकिंग की आवश्यकता है या नहीं। केस बाय केस केस का उपयोग करें।
नेवले की स्थिति कुछ खास होती है।
आशावादी लॉकिंग केवल सरणियों के लिए सक्षम है क्योंकि आंतरिक भंडारण प्रारूप स्थितीय सूचकांक का उपयोग करता है। यह ब्लॉग पोस्ट
द्वारा वर्णित समस्या है। प्रश्न की टिप्पणी में जुड़ा हुआ है। मुझे स्पष्टीकरण
मिला mongoose-orm में दिया गया है मेलिंग सूची बहुत स्पष्ट है:यदि आपको अन्य क्षेत्रों के लिए आशावादी लॉकिंग की आवश्यकता है, तो आपको इसे स्वयं संभालना होगा।
यह रहा एक जिस्ट
add . के लिए पुन:प्रयास करने की रणनीति को लागू करने का तरीका दिखा रहा है संचालन। फिर से, आप इसे कैसे संभालना चाहते हैं यह आपके उपयोग के मामलों पर निर्भर करता है लेकिन यह आपको आरंभ करने के लिए पर्याप्त होना चाहिए।
मुझे उम्मीद है कि इससे चीजें साफ हो जाएंगी।
चीयर्स
