लेन-देन का क्रम संख्या और आइसोलेशन

इस पेज पर, लेन-देन के डेटा के टकराव, सीरियलाइज़ेशन, और आइसोलेशन के बारे में बताया गया है. लेन-देन के कोड सैंपल के लिए, लेन-देन और बैच में कई कार्रवाइयां लिखना लेख देखें.

लेन-देन और डेटा कंटेंशन

किसी लेन-देन को पूरा करने के लिए, रीड ऑपरेशन से वापस लाए गए दस्तावेज़ों में, लेन-देन के बाहर के ऑपरेशन से कोई बदलाव नहीं होना चाहिए. अगर कोई अन्य ऑपरेशन, उन दस्तावेज़ों में से किसी एक में बदलाव करने की कोशिश करता है, तो वह ऑपरेशन, लेन-देन के साथ डेटा कंटेंशन की स्थिति में आ जाता है.

डेटा कंटेंशन

जब दो या उससे ज़्यादा कार्रवाइयां, एक ही दस्तावेज़ को कंट्रोल करने के लिए प्रतिस्पर्धा करती हैं. उदाहरण के लिए, किसी एक लेन-देन के लिए दस्तावेज़ को एक जैसा बनाए रखने की ज़रूरत हो सकती है. वहीं, एक साथ होने वाली कोई दूसरी कार्रवाई उस दस्तावेज़ के फ़ील्ड की वैल्यू को अपडेट करने की कोशिश करती है.

Cloud Firestore किसी एक ऑपरेशन को पूरा होने में ज़्यादा समय लगाकर या उसे पूरा न करके, डेटा से जुड़ी समस्या को हल करता है. Cloud Firestore क्लाइंट लाइब्रेरी, डेटा कंटेंशन की वजह से फ़ेल हुए लेन-देन को अपने-आप फिर से आज़माती हैं. बार-बार कोशिश करने के बाद भी, लेन-देन पूरा नहीं हो पाता. इसके बाद, गड़बड़ी का मैसेज दिखता है:

ABORTED: Too much contention on these documents. Please try again.

यह तय करते समय कि किस ऑपरेशन को पूरा होने में देरी करनी है या किस ऑपरेशन को पूरा नहीं करना है, यह इस बात पर निर्भर करता है कि क्लाइंट लाइब्रेरी किस तरह की है.

Cloud Firestore को कॉन्करेंसी मोड के साथ कॉन्फ़िगर किया जा सकता है: PESSIMISTIC या OPTIMISTIC. Standard वर्शन के लिए डिफ़ॉल्ट वैल्यू PESSIMISTIC है, जबकि Enterprise वर्शन के लिए OPTIMISTIC है. (PESSIMISTIC) का सुझाव दिया जाता है. मोबाइल और वेब SDK टूल, इस सेटिंग से अलग काम करते हैं. ऐसा इसलिए, क्योंकि वे हमेशा ऑप्टिमिस्टिक कंकरेंसी का इस्तेमाल करते हैं.

• मोबाइल/वेब SDK टूल, ऑप्टिमिस्टिक कॉन्करेंसी कंट्रोल का इस्तेमाल करते हैं.

• सर्वर क्लाइंट लाइब्रेरी, पेसिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल करती हैं.

मोबाइल/वेब SDK टूल में डेटा कंटेंशन

मोबाइल और वेब SDK टूल, दस्तावेज़ के वर्शन पर write preconditions का इस्तेमाल करके, ऑप्टिमिस्टिक कंकरेंसी ट्रांज़ैक्शन की नकल करते हैं. यह इम्यूलेशन, डेटाबेस के कॉन्करेंसी मोड की सेटिंग के बावजूद होता है. मोबाइल और वेब SDK टूल, बिल्ट-इन लेन-देन सुविधा का इस्तेमाल नहीं करते. इसलिए, अगर डेटाबेस के कॉन्करेंसी मोड को PESSIMISTIC के लिए कॉन्फ़िगर किया गया है, तो भी मोबाइल क्लाइंट, ऑप्टिमिस्टिक तरीके से काम करते हैं.

ऑप्टिमिस्टिक कॉन्करेंसी कंट्रोल

इस अनुमान के आधार पर कि डेटा कंटेंशन की संभावना कम है या डेटाबेस लॉक को बनाए रखना असरदार नहीं है. ऑप्टिमिस्टिक लेन-देन में, डेटाबेस लॉक का इस्तेमाल नहीं किया जाता. इससे अन्य कार्रवाइयों को डेटा में बदलाव करने से रोका जा सकता है.

मोबाइल/वेब SDK टूल, ऑप्टिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल करते हैं. ऐसा इसलिए, क्योंकि ये ऐसे एनवायरमेंट में काम कर सकते हैं जहां ज़्यादा लेटेन्सी होती है और नेटवर्क कनेक्शन भरोसेमंद नहीं होता. ज़्यादा समय लगने वाले एनवायरमेंट में दस्तावेज़ों को लॉक करने से, डेटा कंटेंशन से जुड़ी कई समस्याएं हो सकती हैं.

मोबाइल/वेब SDK टूल में, किसी ट्रांज़ैक्शन से उन सभी दस्तावेज़ों को ट्रैक किया जाता है जिन्हें आपने ट्रांज़ैक्शन में पढ़ा है. लेन-देन, राइट ऑपरेशन सिर्फ़ तब पूरे करता है, जब लेन-देन के दौरान उन दस्तावेज़ों में कोई बदलाव न हुआ हो. अगर किसी दस्तावेज़ में बदलाव हुआ है, तो लेन-देन को मैनेज करने वाला व्यक्ति, लेन-देन को फिर से पूरा करने की कोशिश करता है. अगर कुछ बार कोशिश करने के बाद भी लेन-देन का नतीजा सही नहीं आता है, तो डेटा कंटेंशन की वजह से लेन-देन पूरा नहीं हो पाता.

सर्वर क्लाइंट लाइब्रेरी में डेटा कंटेंशन

सर्वर क्लाइंट लाइब्रेरी (C#, Go, Java, Node.js, PHP, Python, Ruby) में पहले से मौजूद लेन-देन की सुविधा का इस्तेमाल किया जाता है. यह सुविधा डिफ़ॉल्ट रूप से, ऑप्टिमिस्टिक कंकरेंसी कंट्रोल लागू करती है. ये लेन-देन, डेटाबेस-लेवल के कॉन्करेंसी मोड की सेटिंग (आम तौर पर PESSIMISTIC) का पालन करते हैं. साथ ही, एक साथ कई बार लिखने से होने वाली समस्याओं को रोकने के लिए, दस्तावेज़ों को लॉक करते हैं.

पेसिमिस्टिक कॉनकरेंसी कंट्रोल

इस अनुमान के आधार पर कि डेटा कंटेंशन की समस्या हो सकती है. पेसिमिस्टिक ट्रांज़ैक्शन, डेटाबेस लॉक का इस्तेमाल करते हैं. इससे अन्य कार्रवाइयों को डेटा में बदलाव करने से रोका जा सकता है.

सर्वर क्लाइंट लाइब्रेरी, पेसिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल करती हैं. ऐसा इसलिए, क्योंकि वे कम समय में डेटाबेस से कनेक्ट हो जाती हैं और उनका कनेक्शन भरोसेमंद होता है.

सर्वर क्लाइंट लाइब्रेरी में, लेन-देन उन दस्तावेज़ों पर लॉक लगा देते हैं जिन्हें वे पढ़ते हैं. किसी दस्तावेज़ पर लेन-देन का लॉक होने पर, अन्य लेन-देन, बैच में किए गए राइट ऑपरेशन, और बिना लेन-देन वाले राइट ऑपरेशन उस दस्तावेज़ में बदलाव नहीं कर सकते. कोई लेन-देन, कमिट करने के समय अपने दस्तावेज़ों के लॉक हटा देता है. अगर यह टाइम आउट हो जाता है या किसी वजह से काम नहीं करता है, तो यह अपने लॉक भी रिलीज़ कर देता है.

जब कोई लेन-देन किसी दस्तावेज़ को लॉक करता है, तो लिखने से जुड़ी अन्य कार्रवाइयों को लेन-देन के लॉक हटाने का इंतज़ार करना पड़ता है. लेन-देन, लॉक को क्रम के हिसाब से हासिल करते हैं.

सीरियलाइज़ेबल आइसोलेशन

लेन-देन के बीच डेटा कंटेंशन, डेटाबेस आइसोलेशन लेवल से काफ़ी हद तक जुड़ा होता है. डेटाबेस का आइसोलेशन लेवल यह बताता है कि सिस्टम, एक साथ होने वाले ऑपरेशनों के बीच टकरावों को कितनी अच्छी तरह से मैनेज करता है. डेटाबेस से जुड़ी इन ज़रूरी शर्तों की वजह से टकराव होता है:

• लेन-देन के लिए सटीक और एक जैसा डेटा ज़रूरी होता है.
• संसाधनों का बेहतर तरीके से इस्तेमाल करने के लिए, डेटाबेस एक साथ कई कार्रवाइयां करते हैं.

कम आइसोलेशन लेवल वाले सिस्टम में, किसी लेन-देन के दौरान रीड ऑपरेशन, एक साथ होने वाले ऑपरेशन में बिना कमिट किए गए बदलावों से गलत डेटा पढ़ सकता है.

सीरियलाइज़ेबल आइसोलेशन, आइसोलेशन का सबसे ऊंचा लेवल तय करता है. सीरियलाइज़ेबल आइसोलेशन का मतलब है कि:

• यह माना जा सकता है कि डेटाबेस, लेन-देन को क्रम से पूरा करता है.
• एक साथ होने वाली कार्रवाइयों में, बिना कमिट किए गए बदलावों से लेन-देन पर कोई असर नहीं पड़ता.

डेटाबेस में एक साथ कई ट्रांज़ैक्शन होने पर भी, इस गारंटी का पालन किया जाना चाहिए. डेटाबेस में, एक साथ कई अनुरोधों को मैनेज करने की सुविधा होनी चाहिए, ताकि इस गारंटी का उल्लंघन करने वाले विवादों को हल किया जा सके.

Cloud Firestore लेन-देन के लिए, सीरियलाइज़ेबल आइसोलेशन की गारंटी देता है. Cloud Firestore में लेन-देन को क्रम से लगाया जाता है और कमिट टाइम के हिसाब से अलग किया जाता है.

कमिट टाइम के हिसाब से क्रम से लगाया जा सकने वाला आइसोलेशन

Cloud Firestore हर लेन-देन को कमिट करने का समय असाइन करता है. यह समय, किसी एक पॉइंट इन टाइम को दिखाता है. जब Cloud Firestore किसी लेन-देन के बदलावों को डेटाबेस में सेव करता है, तो यह माना जा सकता है कि लेन-देन के दौरान किए गए सभी रीड और राइट ऑपरेशन, कमिट के समय ही हुए हैं.

किसी लेन-देन को पूरा होने में कुछ समय लगता है. किसी लेन-देन को कमिट करने से पहले ही उसे लागू करना शुरू कर दिया जाता है. साथ ही, एक साथ कई कार्रवाइयां की जा सकती हैं. Cloud Firestore सीरियलाइज़ेबल आइसोलेशन को बनाए रखता है और यह गारंटी देता है कि:

• Cloud Firestore, लेन-देन को कमिट करने के समय के हिसाब से क्रम में लगाता है.
• Cloud Firestore, एक साथ होने वाले लेन-देन को अलग करता है. साथ ही, बाद में कमिट किए जाने वाले लेन-देन को भी अलग करता है.

एक साथ होने वाली कार्रवाइयों के बीच डेटा कंटेंशन के मामले में, Cloud Firestore कंटेंशन को हल करने के लिए, ऑप्टिमिस्टिक और पेसिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल करता है.

लेन-देन के दौरान डेटा को अलग रखना

लेन-देन के दौरान डेटा में बदलाव करने की कार्रवाइयों पर भी लेन-देन आइसोलेशन लागू होता है. किसी लेन-देन के दौरान की गई क्वेरी और रीड, उस लेन-देन के दौरान किए गए पिछले राइट के नतीजे नहीं देखती हैं. अगर किसी लेन-देन में मौजूद दस्तावेज़ में बदलाव किया जाता है या उसे मिटाया जाता है, तब भी उस लेन-देन में दस्तावेज़ को पढ़ने के सभी अनुरोध, कमिट करने के समय के दस्तावेज़ का वर्शन दिखाते हैं. यह लेन-देन के लिखने के ऑपरेशन से पहले होता है. अगर दस्तावेज़ मौजूद नहीं है, तो पढ़ने की कार्रवाइयों से कोई वैल्यू नहीं मिलती.

डेटा कंटेंशन से जुड़ी समस्याएं

डेटा कंटेंशन और उन्हें हल करने के तरीके के बारे में ज़्यादा जानने के लिए, समस्या हल करने वाला पेज देखें.