ताले (जेपीए) से कैसे निपटें?

Question

Java Persistent/Locking wikibooks * के अनुसार, ताले से निपटने का सबसे अच्छा तरीका उपयोगकर्ता को आशावादी लॉक त्रुटि/अपवाद की रिपोर्ट करना है।

समस्या यह है कि यह मापनीय नहीं है। मान लीजिए कि मेरे पास कई उपयोगकर्ता हैं जो एक ही कार्रवाई के साथ लॉक का कारण बन सकते हैं। उपयोगकर्ता को लॉक त्रुटि संदेश की परवाह नहीं है।

संक्षेप में:

• सबसे अच्छा तरीका सभी ताले निष्क्रिय करने के लिए है?
• उपयोगकर्ता को त्रुटि लॉक संदेश की रिपोर्ट करना सबसे अच्छा तरीका है? लेकिन जब तक यह काम नहीं करेगा तब तक उपयोगकर्ता को अपनी कार्रवाई फिर से करनी होगी!
• लेन-देन का पुन: प्रयास करने का सबसे अच्छा तरीका है जब तक कोई लॉक न हो?

---

*

हैंडलिंग आशावादी लॉक अपवाद

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

यह वास्तव में पहली जगह लॉकिंग के पूरे बिंदु को हरा देता है। यदि आप यही चाहते हैं, तो आप लॉकिंग का भी उपयोग कर सकते हैं। दुर्भाग्य से, OptimisticLockException को शायद ही कभी स्वचालित रूप से संभाला जाना चाहिए, और आपको वास्तव में इस मुद्दे के बारे में उपयोगकर्ता को परेशान करने की आवश्यकता है। आपको उपयोगकर्ता को संघर्ष की रिपोर्ट करनी चाहिए, और या तो "आपका खेद है लेकिन एक संपादन विवाद हुआ और उन्हें अपने काम को फिर से करना होगा", या सबसे अच्छे मामले में, ऑब्जेक्ट को रीफ्रेश करें और उपयोगकर्ता को वर्तमान डेटा के साथ प्रस्तुत करें और वह डेटा जो उन्होंने सबमिट किया है और यदि उपयुक्त हो तो दोनों को मर्ज करने में उनकी सहायता करें।

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

Answer 1

उपयोगकर्ता संदेश के बारे में परवाह करेगा, क्योंकि वह कुछ संशोधन करना चाहता था, और संशोधन नहीं किए गए हैं। इस प्रकार वह डेटा की नई स्थिति देखने के लिए पेज को रीफ्रेश करेगा, और अपने संशोधनों को फिर से कर देगा, या फैसला करेगा कि उन्हें अब नया राज्य नहीं दिया जाना चाहिए।

क्या यह समस्या है यदि दो उपयोगकर्ता एक साथ एक इकाई को संशोधित करते हैं, और यदि अंतिम संशोधन जीतता है, जो भी संशोधन है? यदि यह एक समस्या है, तो आशावादी लॉकिंग का उपयोग करें, और समस्या होने पर अपने उपयोगकर्ता को सूचित करें। इसके चारों ओर कोई रास्ता नहीं है।

यदि यह कोई समस्या नहीं है, तो आशावादी लॉकिंग का उपयोग न करें। अंतिम संशोधन, यदि यह आपके डेटाबेस में बाधाओं को तोड़ता नहीं है, तो हमेशा जीत जाएगा।लेकिन एक ही डेटा को संशोधित करने वाले समवर्ती उपयोगकर्ता होने पर हमेशा अपवादों का कारण बनता है (उदाहरण के लिए, क्योंकि कुछ उपयोगकर्ता किसी अन्य उपयोगकर्ता को एक ही इकाई में संशोधन सबमिट करने से पहले एक इकाई को हटा सकता है)।

पुनः प्रयास कर रहा एक विकल्प नहीं है:

• या तो यह, फिर से असफल हो जायेगी, क्योंकि यह संशोधन
• या यह सफल होगा करने के लिए संभव नहीं है, लेकिन में आशावादी लॉक होने की बात को हराने होगा पहले स्थान पर।

आपकी समस्या को कार समरूपता के साथ समझाया जा सकता है। मान लें कि आप स्पीड लिमिटर के साथ एक कार खरीदना चुनते हैं ताकि यह सुनिश्चित किया जा सके कि आप गति सीमा को तोड़ नहीं सकते हैं। और अब आप पूछते हैं: लेकिन मुझे गति सीमा की परवाह नहीं है। क्या मैं हमेशा गति limiter अक्षम नहीं करना चाहिए? आप कर सकते हैं, लेकिन अगर आप पुलिस द्वारा पकड़े गए तो आश्चर्यचकित न हों।