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

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

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

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

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

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 टूल, दस्तावेज़ के वर्शन पर लिखने की पूर्व शर्तों का इस्तेमाल करके, ऑप्टिमिस्टिक कंकरेंसी ट्रांज़ैक्शन का अनुकरण करते हैं. यह इम्यूलेशन, डेटाबेस के कॉन्करेंसी मोड की सेटिंग के बावजूद होता है. मोबाइल और वेब 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 कंटेंशन को हल करने के लिए, ऑप्टिमिस्टिक और पेसिमिस्टिक कंकरेंसी कंट्रोल का इस्तेमाल करता है.

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

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

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

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