आपके प्रश्न में आपका उदाहरण दिखाता है कि लॉकिंग का क्रम एक्सेस विधि पर निर्भर करता है। यह एक्सेस पथ सीधे क्वेरी के ORDER BY क्लॉज द्वारा तय नहीं किया जाता है, ऐसे कई कारक हैं जो इस एक्सेस पथ को प्रभावित कर सकते हैं। इसलिए, आप केवल ORDER BY जोड़कर गतिरोध को नहीं रोक सकते क्योंकि आपके पास अभी भी दो अलग-अलग पहुंच पथ हो सकते हैं। वास्तव में आपके परीक्षण मामले को क्रम के साथ चलाकर और सत्र मापदंडों को बदलकर मैं एक ही प्रश्न के साथ दो सत्रों को ORA-60 में चलाने में सक्षम था।
यदि शामिल सत्रों में कोई अन्य लॉक लंबित नहीं है, तो पंक्तियों को लॉक करना उसी क्रम में सभी सत्रों में गतिरोध को रोका जा सकेगा लेकिन आप इस आदेश को मज़बूती से कैसे लागू कर सकते हैं? ध्यान दें कि यह वैसे भी गतिरोध के इस विशेष मामले को ही रोकेगा। आप अभी भी प्रत्येक सत्र या विभिन्न योजनाओं में कई प्रश्नों के साथ गतिरोध प्राप्त कर सकते हैं।
व्यवहार में यह मामला वास्तव में विशेष है और वैसे भी अक्सर नहीं होना चाहिए:यदि आप गतिरोध के बारे में चिंतित हैं, तो मुझे अभी भी लगता है कि उन्हें रोकने के लिए आसान तरीके हैं।
किसी गतिरोध को रोकने का सबसे आसान तरीका FOR UPDATE NOWAIT . का उपयोग करना है या FOR UPDATE WAIT X (हालांकि WAIT X अभी भी डेडलॉक डिटेक्शन मैकेनिज्म से बेहतर X के मानों के साथ एक गतिरोध को ट्रिगर कर सकता है, वर्तमान में 11g के अनुसार 3 सेकंड मुझे विश्वास है - धन्यवाद @APC
सुधार के लिए)।
दूसरे शब्दों में, दोनों लेन-देन को पूछना चाहिए:मुझे उन पंक्तियों को दें और उन्हें लॉक करें लेकिन यदि किसी अन्य उपयोगकर्ता के पास पहले से ही लॉक है तो अनिश्चित काल तक प्रतीक्षा करने के बजाय एक त्रुटि लौटाएं। यह अनिश्चितकालीन प्रतीक्षा है जो गतिरोध का कारण बनती है।
व्यवहार में मैं कहूंगा कि वास्तविक व्यक्ति उपयोगकर्ताओं के साथ अधिकांश एप्लिकेशन एक लेन-देन समाप्त होने के लिए अनिश्चित काल तक प्रतीक्षा करने के बजाय तुरंत एक त्रुटि प्राप्त करेंगे। मैं FOR UPDATE consider पर विचार करूंगा बिना NOWAIT . के केवल गैर-महत्वपूर्ण बैच की नौकरियों के लिए।
