ऑप्टिमिस्टिक लॉकिंग एक रणनीति है जहां आप एक रिकॉर्ड पढ़ते हैं, एक संस्करण संख्या पर ध्यान दें (ऐसा करने के लिए अन्य तरीकों में तिथियां, टाइमस्टैम्प या चेकसम/हैश शामिल हैं) और जांचें कि रिकॉर्ड वापस लिखने से पहले संस्करण नहीं बदला है। जब आप रिकॉर्ड वापस लिखते हैं तो आप यह सुनिश्चित करने के लिए संस्करण पर अद्यतन फ़िल्टर करते हैं कि यह परमाणु है। (यानी जब आप संस्करण की जांच करते हैं और डिस्क पर रिकॉर्ड लिखते हैं, तब तक अपडेट नहीं किया गया है) और संस्करण को एक हिट में अपडेट करें।
यदि रिकॉर्ड गंदा है (यानी आपका अलग संस्करण) तो आप लेन-देन को रोक देते हैं और उपयोगकर्ता इसे फिर से शुरू कर सकता है।
यह रणनीति उच्च-मात्रा वाले सिस्टम और त्रि-स्तरीय आर्किटेक्चर पर सबसे अधिक लागू होती है, जहां आप अपने सत्र के लिए डेटाबेस से कनेक्शन को जरूरी नहीं रखते हैं। इस स्थिति में क्लाइंट वास्तव में डेटाबेस लॉक को बनाए नहीं रख सकता क्योंकि कनेक्शन पूल से लिए जाते हैं और हो सकता है कि आप एक ही कनेक्शन का उपयोग एक एक्सेस से दूसरे एक्सेस में नहीं कर रहे हों।
निराशावादी लॉकिंग तब होती है जब आप अपने विशेष उपयोग के लिए रिकॉर्ड को तब तक लॉक करते हैं जब तक कि आप इसे समाप्त नहीं कर लेते। आशावादी लॉकिंग की तुलना में इसकी बेहतर अखंडता है लेकिन आपको डेडलॉक से बचने के लिए अपने एप्लिकेशन डिज़ाइन से सावधान रहने की आवश्यकता है। निराशावादी लॉकिंग का उपयोग करने के लिए आपको या तो डेटाबेस से सीधे कनेक्शन की आवश्यकता होती है (जैसा कि आमतौर पर दो स्तरीय क्लाइंट सर्वर एप्लिकेशन में होता है) या बाहरी रूप से उपलब्ध लेनदेन आईडी जिसे कनेक्शन से स्वतंत्र रूप से उपयोग किया जा सकता है।
बाद के मामले में आप TxID के साथ लेन-देन खोलते हैं और फिर उस आईडी का उपयोग करके पुनः कनेक्ट करते हैं। DBMS ताले को बनाए रखता है और आपको TxID के माध्यम से सत्र का बैकअप लेने की अनुमति देता है। दो-चरण प्रतिबद्ध प्रोटोकॉल (जैसे XA या COM+ लेनदेन) का उपयोग करके वितरित लेनदेन इस प्रकार काम करते हैं।
