लॉकमोड टाइप जेपीए के बीच अंतर

मैं पहले आशावादी और निराशावादी तालों में अंतर करूँगा, क्योंकि वे अपने अंतर्निहित तंत्र में भिन्न हैं।

आशावादी लॉकिंग पूरी तरह से जेपीए द्वारा नियंत्रित है और केवल डीबी टेबल में अतिरिक्त संस्करण कॉलम की आवश्यकता है। यह रिलेशनल डेटा को स्टोर करने के लिए उपयोग किए जाने वाले अंतर्निहित डीबी इंजन से पूरी तरह से स्वतंत्र है।

दूसरी ओर, निराशावादी लॉकिंग टेबल में मौजूदा रिकॉर्ड को लॉक करने के लिए अंतर्निहित डेटाबेस द्वारा प्रदान किए गए लॉकिंग तंत्र का उपयोग करता है। जेपीए को यह जानने की जरूरत है कि इन तालों को कैसे ट्रिगर किया जाए और कुछ डेटाबेस उनका समर्थन नहीं करते या केवल आंशिक रूप से।

अब लॉक प्रकारों की सूची पर:

1. LockModeType.Optimistic
   • यदि निकाय एक संस्करण फ़ील्ड निर्दिष्ट करते हैं, तो यह डिफ़ॉल्ट है। संस्करण कॉलम के बिना इकाइयों के लिए, इस प्रकार के लॉक का उपयोग किसी भी जेपीए कार्यान्वयन पर काम करने की गारंटी नहीं है। ऑब्जेक्टडीबी द्वारा बताए गए अनुसार इस मोड को आमतौर पर अनदेखा किया जाता है। मेरी राय में यह केवल इसलिए मौजूद है ताकि आप लॉक मोड को गतिशील रूप से गणना कर सकें और इसे आगे भी पास कर सकें, भले ही लॉक अंत में ऑप्टिमिस्टिक हो। हालांकि बहुत संभावित उपयोगकेस नहीं है, लेकिन डिफ़ॉल्ट मान को भी संदर्भित करने का विकल्प प्रदान करने के लिए यह हमेशा अच्छा एपीआई डिज़ाइन होता है।

• उदाहरण:

     `LockModeType lockMode = resolveLockMode();
   A a = em.find(A.class, 1, lockMode);`
  

2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

• यह शायद ही कभी इस्तेमाल किया जाने वाला विकल्प है। लेकिन यह उचित हो सकता है, अगर आप इस इकाई को किसी अन्य इकाई द्वारा संदर्भित करना लॉक करना चाहते हैं। दूसरे शब्दों में आप किसी इकाई के साथ काम करना लॉक करना चाहते हैं, भले ही वह संशोधित न हो, लेकिन इस इकाई के संबंध में अन्य संस्थाओं को संशोधित किया जा सकता है।
• उदाहरण:हमारे पास इकाई बुक और शेल्फ है। बुक को शेल्फ में जोड़ना संभव है, लेकिन बुक में इसके शेल्फ का कोई संदर्भ नहीं है। किसी पुस्तक को शेल्फ में ले जाने की क्रिया को लॉक करना उचित है, ताकि इस लेन-देन के अंत से पहले एक पुस्तक दूसरे शेल्फ (दूसरे लेनदेन के कारण) में समाप्त न हो। इस क्रिया को लॉक करने के लिए, वर्तमान बुक शेल्फ इकाई को लॉक करना पर्याप्त नहीं है, क्योंकि पुस्तक को अभी तक शेल्फ पर होना आवश्यक नहीं है। सभी लक्षित बुकशेल्फ़ को लॉक करने का भी कोई मतलब नहीं है, क्योंकि वे अलग-अलग लेन-देन में अलग-अलग होंगे। केवल एक चीज जो समझ में आती है वह है पुस्तक इकाई को स्वयं लॉक करना, भले ही हमारे मामले में यह परिवर्तित न हो (इसमें इसके बुकशेल्फ़ का संदर्भ नहीं है)।

3. LockModeType.PESSIMISTIC_READ

• यह मोड LockModeType.PESSIMISTIC_WRITE के समान है , लेकिन एक बात में अलग:जब तक कि कुछ लेन-देन द्वारा एक ही इकाई पर राइट लॉक नहीं होता है, तब तक उसे इकाई को पढ़ना ब्लॉक नहीं करना चाहिए। यह LockModeType.PESSIMISTIC_READ . का उपयोग करके अन्य लेनदेन को भी लॉक करने की अनुमति देता है . WRITE और READ ताले के बीच के अंतर को यहाँ (ObjectDB) और यहाँ (OpenJPA) के बीच अच्छी तरह से समझाया गया है। यदि कोई इकाई पहले से ही किसी अन्य लेन-देन द्वारा बंद है, तो इसे लॉक करने का कोई भी प्रयास अपवाद फेंक देगा। इस व्यवहार को कुछ समय के लिए प्रतीक्षा करने के लिए संशोधित किया जा सकता है ताकि अपवाद को फेंकने से पहले लॉक को रिलीज़ किया जा सके और लेनदेन को वापस रोल किया जा सके। ऐसा करने के लिए, javax.persistence.lock.timeout निर्दिष्ट करें अपवाद फेंकने से पहले प्रतीक्षा करने के लिए मिलीसेकंड की संख्या के साथ संकेत दें। जावा ईई ट्यूटोरियल में वर्णित कई स्तरों पर इसे करने के कई तरीके हैं।

4. LockModeType.PESSIMISTIC_WRITE

• यह LockModeType.PESSIMISTIC_READ का एक मजबूत संस्करण है . जब WRITE लॉक जगह पर है, डेटाबेस की मदद से जेपीए किसी भी अन्य लेनदेन को इकाई को पढ़ने से रोकेगा, न केवल READ के साथ लिखने के लिए ताला।
• अंतर्निहित डीबी के सहयोग से जेपीए प्रदाता में इसे कैसे लागू किया जाता है, यह निर्धारित नहीं है। Oracle के मामले में, मैं कहूंगा कि Oracle READ . के करीब कुछ प्रदान नहीं करता है ताला। SELECT...FOR UPDATE वास्तव में एक WRITE है ताला। यह हाइबरनेट में एक बग हो सकता है या सिर्फ एक निर्णय हो सकता है कि, कस्टम "सॉफ्टर" को लागू करने के बजाय READ लॉक, "कठिन" WRITE इसके बजाय लॉक का उपयोग किया जाता है। यह ज्यादातर एकरूपता को नहीं तोड़ता है, लेकिन READ . के साथ सभी नियमों को नहीं रखता है ताले आप READ . के साथ कुछ सरल परीक्षण चला सकते हैं लॉक और लंबे समय तक चलने वाले लेन-देन यह पता लगाने के लिए कि क्या अधिक लेनदेन READ प्राप्त करने में सक्षम हैं एक ही इकाई पर ताले। यह संभव होना चाहिए, जबकि WRITE . के साथ नहीं ताले।

5. LockModeType.PESSIMISTIC_FORCE_INCREMENT

• यह एक और शायद ही कभी इस्तेमाल किया जाने वाला लॉक मोड है। हालाँकि, यह एक विकल्प है जहाँ आपको PESSIMISTIC . को संयोजित करने की आवश्यकता है और OPTIMISTIC तंत्र। सादे PESSIMISTIC_WRITE का उपयोग करना निम्नलिखित परिदृश्य में विफल होगा:
  1. लेन-देन ए आशावादी लॉकिंग का उपयोग करता है और इकाई ई पढ़ता है
  2. लेन-देन बी ने इकाई ई पर राइट लॉक प्राप्त किया
  3. लेन-देन B, E का लॉक करता है और जारी करता है
  4. लेन-देन A, E को अपडेट करता है और प्रतिबद्ध करता है
• चरण 4 में, यदि संस्करण स्तंभ में लेन-देन B से वृद्धि नहीं होती है, तो A को B के परिवर्तनों को अधिलेखित करने से कुछ भी नहीं रोकता है। लॉक मोड LockModeType.PESSIMISTIC_FORCE_INCREMENT लेन-देन बी को संस्करण संख्या को अपडेट करने के लिए मजबूर करेगा और लेनदेन ए को OptimisticLockException के साथ विफल कर देगा , भले ही B निराशावादी लॉकिंग का उपयोग कर रहा था।

6. LockModeType.NONE

• यदि निकाय संस्करण फ़ील्ड प्रदान नहीं करते हैं तो यह डिफ़ॉल्ट है। इसका मतलब है कि कोई भी लॉकिंग सक्षम नहीं है, संघर्षों को सर्वोत्तम प्रयास के आधार पर हल किया जाएगा और इसका पता नहीं लगाया जाएगा। लेन-देन के बाहर यह एकमात्र लॉक मोड की अनुमति है