सबसे पहले, किसी तालिका को लॉक करना दूसरे सत्र को SELECT issuing जारी करने से नहीं रोकेगा डेटा के खिलाफ बयान।
सत्र 1 में, अगर मैं टेबल को लॉक कर दूं
SQL> lock table foo in exclusive mode;
Table(s) Locked.
फिर मैं सत्र 2 शुरू कर सकता हूं और अपने इच्छित सभी डेटा को क्वेरी कर सकता हूं
SQL> select * from foo;
COL1
----------
1
1
Oracle में, लेखक पाठकों को ब्लॉक नहीं करते हैं, इसलिए आप किसी अन्य सत्र को किसी तालिका में डेटा को क्वेरी करने से कभी नहीं रोक सकते हैं।
ऐसा लगता है कि आप जो लागू करने की कोशिश कर रहे हैं वह निराशावादी लॉकिंग है। उस स्थिति में, तालिका को लॉक करने के बजाय, आप SELECT FOR UPDATE . करते हैं जो उस विशेष प्रविष्टि को लॉक कर देता है जिसे आप संसाधित करना चाहते हैं। जब तक अन्य सभी सत्र भी SELECT FOR UPDATE . करने का प्रयास करते हैं (Oracle संस्करण के आधार पर, संभावित रूप से SKIP LOCKED . जोड़ना क्वालीफायर और/या WAIT क्वालीफायर)। यह उस विशिष्ट पंक्ति को लॉक कर देता है जिसे आप संसाधित कर रहे हैं और दूसरे सत्र को या तो एक अलग पंक्ति या समय समाप्त करने देता है या पता चलता है कि कार्यान्वयन की बारीकियों के आधार पर संसाधित करने के लिए कोई पंक्तियाँ नहीं हैं। इसमें टेबल को लॉक करना शामिल नहीं है।
लॉक जारी करने का एकमात्र तरीका उस सत्र के लिए है जिसने इसे जारी करने के लिए इसे प्राप्त किया है (आमतौर पर लेनदेन को समाप्त करके) या उस सत्र के लिए जिसने इसे समाप्त करने के लिए अधिग्रहित किया है। यदि क्लाइंट एप्लिकेशन अभी भी चल रहा है, लेकिन लॉक जारी करने या सत्र को समाप्त करने के लिए कुछ नहीं कर रहा है, तो लॉक अनिश्चित काल के लिए आयोजित किया जाएगा। एक डीबीए को सत्र को स्पष्ट रूप से समाप्त करने की आवश्यकता होगी, जिससे लेन-देन वापस आ जाए और सिस्टम को फिर से चालू करने के लिए लॉक जारी किया जाए। यदि क्लाइंट एप्लिकेशन चलना बंद कर देता है या, कम से कम, प्रतिक्रिया देना बंद कर देता है (मैं अभी भी स्पष्ट नहीं हूं कि आप किस विफलता परिदृश्य पर चर्चा कर रहे हैं), यह संभव है कि 'SQLNET.EXPIRE_TIME' पैरामीटर डेटाबेस स्तर पर डेटाबेस को यह निर्धारित करने का कारण होगा कि क्लाइंट गैर-प्रतिक्रियाशील है और स्वचालित रूप से सत्र को समाप्त कर देगा, लेनदेन को वापस ले जाएगा और लॉक जारी करेगा।
यदि डेटा को संसाधित करने के लिए कई सत्र हैं, तो आमतौर पर आशावादी लॉकिंग के किसी न किसी रूप का उपयोग करना बेहतर होता है। अन्यथा, आप एक ऐसी प्रणाली तैयार कर रहे हैं जिसे अनिवार्य रूप से व्यावसायिक उपयोगकर्ताओं को फिर से काम करने के लिए सत्रों को खोजने और मारने के लिए डीबीए की आवश्यकता होगी और इसके लिए जितना व्यस्त हो उतना अधिक हस्तक्षेप की आवश्यकता होगी। ऐसा कुछ नहीं है जिसे डीबीए करना पसंद करते हैं और कुछ व्यवसायिक उपयोगकर्ता इसके बारे में शिकायत करने का आनंद नहीं लेते हैं। एक साधारण आशावादी लॉकिंग योजना कुछ इस तरह होगी
- संसाधित करने के लिए एक कुंजी और किसी प्रकार की तिथि का चयन करें जो पिछली बार पंक्ति को अद्यतन करने का संकेत देती है।
- एक स्थिति कॉलम को "प्रोसेसिंग" में अपडेट करें ताकि अन्य सत्र उसी पंक्ति को संसाधित करने का प्रयास न करें।
- अपने आवेदन में प्रविष्टि की प्रक्रिया करें
- जब आप प्रोसेसिंग पूरी कर लें, तो कुंजी और पहले चरण में आपके द्वारा चुने गए समय का उपयोग करके डेटा अपडेट करें। यदि आप 1 पंक्ति को अपडेट करते हैं, तो आप जानते हैं कि आपके द्वारा चयनित डेटा को किसी अन्य सत्र ने संशोधित नहीं किया है। यदि आप 0 पंक्तियों को अपडेट करते हैं, तो आप जानते हैं कि आपके द्वारा चुने जाने के बाद से किसी अन्य सत्र ने डेटा को संशोधित किया है।
इस प्रकार के आर्किटेक्चर के साथ, यह देखने के लिए डेटाबेस से पूछताछ करना अपेक्षाकृत आसान है कि कौन सी पंक्तियों को संसाधित किया जा रहा है और उदाहरण के लिए, एक नौकरी है जो कुछ समय के बाद स्थिति कॉलम को "असंसाधित" पर सेट करती है यदि क्लाइंट के पास नहीं है खत्म। अन्य सत्रों के लिए प्रक्रिया के लिए एक अलग पंक्ति चुनना वास्तव में आसान है। और यह अपेक्षाकृत सुरक्षित है यदि, उदाहरण के लिए, एप्लिकेशन कुछ घंटों के लिए फ़्रीज़ हो जाता है और फिर ठीक हो जाता है क्योंकि यह केवल एक बार संसाधित होने के बाद पाता है कि कोई अन्य सत्र पहले ही पंक्ति को फिर से संसाधित कर चुका है।
