2009-09-07 18 views
5

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

मेरी समस्या फ्रंट एंड के साथ नहीं है, बैक एंड के साथ नहीं। मेरे पृष्ठों को डिज़ाइन करने के लिए मैं किस पैटर्न का उपयोग कर सकता हूं ताकि उपयोगकर्ता के अनुकूल दोनों हो और समवर्ती संशोधन को रोक सकें? एक वेब वातावरण जहां मैं सत्र के लिए ज्यादातर मामलों में ताला जारी करने के लिए सक्षम होने से पहले का समय-समाप्त करने के लिए इंतजार करना होगा में मुश्किल:

  • निराशावादी ताला: केवल दो विकल्प मैं के बारे में सोच सकते हैं इन कर रहे हैं।
  • आशावादी लॉकिंग: उपयोगकर्ता-मित्रता के मामले में यह अच्छा नहीं है, क्योंकि उपयोगकर्ता अंत में केवल "सहेज नहीं सकते" संदेश के साथ स्वागत करने के लिए एक बड़े रूप में भर सकता है।

कोई सुझाव?

+0

आशावादी लॉकिंग के पास उपयोगकर्ता के अनुकूल होने या अन्यथा होने के साथ कुछ लेना देना नहीं है; यह कार्यान्वयन के लिए नीचे है। बड़ा सवाल यह है कि एक ही रिकॉर्ड पर एक साथ संपादन की अपेक्षित आवृत्ति क्या है? यदि कम, सरल आशावादी लॉकिंग जीतती है। – SteveD

उत्तर

2

एक समय के आरक्षण के बारे में कैसे? यह एक मॉडल है जो ऑनलाइन ऑन-लाइन बुकिंग सिस्टम में उपयोग किया जाता है।

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

आशावादी लॉकिंग के साथ संयोजन में इसका उपयोग करें। बिंदु पर आप संपादन मोड में जाने आप

  • रिकार्ड के लिए एक आरक्षण करें आप अब जहां कुंजी = आईडी और RESERVATION_TIME 30 से अधिक मिनट पहले

अद्यतन RESERVATION_TIME चाहते यह केवल तभी काम करेगा जब कोई भी हाल ही में अपडेट अप सेट नहीं कर चुका है। विचार यह है कि अगर कोई अन्य उपयोगकर्ता पहले से ही काम कर रहा है तो हम संपादन स्क्रीन को पॉप्युलेट करने की अनुमति भी नहीं देते हैं। लेकिन हमने उस आरक्षण को 30 मिनट (या जो कुछ भी) के बाद समाप्त करने के लिए सेट किया है ताकि कुछ भी "लॉक" पर निर्भर न हो। लेकिन ध्यान दें कि हम एक निराशावादी ताला रखने वाले डेटाबेस डेटाबेस में नहीं हैं।

  • अब वापस लिखने पर डेटा पुनः प्राप्त (शायद सराय ही ट्रॅन के रूप में आरक्षण लिया)

  • आशावादी विधेय की जाँच करें और आरक्षण एक लंबे समय पहले वापस करने के लिए साफ़ करें।

अब यह आरक्षण प्रणाली का सम्मान करने वाले किसी भी एप्लिकेशन के दो उपयोगकर्ताओं के बीच मध्यस्थता करता है। ऑप्टिस्टिक लॉक सिस्टम के सभी आशावादी उपयोगकर्ताओं के बीच मध्यस्थता करता है, इसलिए उपयोगकर्ता के लिए परेशान होना अभी भी संभव है, लेकिन यह मान लें कि आउट-ऑफ-बैंड अपडेट दुर्लभ हैं, तो आपको स्वीकार्य उपयोगिता प्राप्त करनी चाहिए।

कुछ अन्य विचार:

  1. अंतिम बचाने जीत - कुछ डेटा के लिए लॉकिंग का कोई मतलब नहीं है। आप उपयोगकर्ता बिल को ऐलिस के काम को बदलने के लिए अनुमति देने जा रहे थे और इसके विपरीत, तो जीतने की अनुमति दें।
  2. संघर्ष का पता लगाएं और विलय करें। सीवीएस स्रोत नियंत्रण प्रणाली की तरह। एक आशावादी योजना का उपयोग करें और संघर्ष की स्थिति में हस्तक्षेप अद्यतन और प्रस्तावित अद्यतन प्रस्तुत करें और उपयोगकर्ता को संघर्ष को हल करने के लिए कहें।
+0

सुझावों के लिए धन्यवाद, लेकिन क्या आप कृपया अपने आरक्षण सुझाव पर विस्तृत जानकारी दे सकते हैं।मैं काफी अनुवर्ती नहीं हूं - क्या आपका मतलब है कि मुझे आरक्षण की तरह निराशावादी लॉकिंग का उपयोग करना चाहिए, लेकिन यदि आपके पास अनन्य लॉक नहीं है तो आशावादी लॉकिंग की भी अनुमति दें? – Zecrates

+0

उत्तर थोड़ा – djna

1

हम इसी तरह की परिस्थितियों में एक प्रथम लिख जीत तंत्र (या आशावादी लॉकिंग) को लागू

बैकएंड

डेटाबेस में एक टाइमस्टैम्प क्षेत्र बनाना होगा (यह स्वचालित रूप से पर MSSQL में अद्यतन किया जाता है एक INSERT और अद्यतन)

जब आप एक टाइमस्टैम्प संपत्ति समेत संपादन के लिए ऑब्जेक्ट लोड करते हैं, तो केवल आपके संग्रहित प्रक्रियाओं में बचत की अनुमति दें यदि टाइमस्टैम्प एक ही त्रुटि है, तो इसे अपने एप्लिकेशन में संभाल लें यह दर्शाता है कि रिकॉर्ड बदल गया है और उन्हें पृष्ठ को फिर से लोड करने का मौका दिया गया है। यह वेब/डिस्कनेक्टेड वातावरण पर अच्छी तरह से काम करता है।

सामने अंत

पेज एक परिवर्तन का पता लगाने के डेटाबेस (ajax का प्रयोग करके) मतदान की जरूरत है। यदि कोई परिवर्तन संकेत होता है तो उपयोगकर्ता इंगित करता है कि रिकॉर्ड बदल गया है और पुनः लोड/विलय करने का विकल्प है। पृष्ठ पर पोस्टबैक डिस्प्ले लेबल्स या द्वितीयक फॉर्म फ़ील्ड्स (केवल पढ़ने के लिए) दाईं ओर दिए गए नए दर्ज मूल्यों के साथ, उदाहरण के लिए तीर बटन इंगित किया जाता है जो मूल्यों को मूल रूप फ़ील्ड में प्रतिलिपि बनाता है।

+0

अद्यतन किया गया है आशावादी लॉकिंग यह नहीं है? और फिर से लोड करने वाला समस्या प्रश्नकर्ता है - अगर गह उपयोगकर्ता ने यूआई में बहुत सारी विस्तृत जानकारी भरने में 10 मिनट खर्च किए हैं तो गहराई से दुखी है। "बहुत देर तक हमें पहले मिल गया! इसे फिर से टाइप करें।" – djna

+0

"आशावादी लॉकिंग" और अच्छी बात :-) धन्यवाद। उत्तर अपडेट किया गया। –

0

मैं आपसे सहमत हूं कि आशावादी लॉकिंग उपयोगकर्ता के अनुकूल नहीं है।

निराशावादी लॉकिंग के लिए, मुझे लगता है कि आप इस समस्या को खत्म कर सकते हैं:

  • अधिक बार अवरोध खोल लिए, आप एक delai ताला के लिए, अपने डेटाबेस में इस्तेमाल कर सकते हैं। उस डेलाई की समाप्ति के बाद, एक और उपयोगकर्ता लॉक तोड़ सकता है। पहले उपयोगकर्ता को इसकी सूचना दी जाएगी। शुरुआत से ही स्पष्ट होना चाहिए।

  • आप लॉकिंग पृष्ठ में आवर्ती ऑटो-रीफ्रेश का भी उपयोग कर सकते हैं। प्रत्येक (AJAX) अनुरोध पर, आप समय याद करते हैं। इसलिए, यदि सर्वर पर, ताला ताज़ा दर से पुराना है, तो इसका मतलब है कि उपयोगकर्ता अब इस पृष्ठ पर नहीं है। तो सत्र समाप्त होने के बावजूद, आप लॉक को साफ कर सकते हैं।

0

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

आप इसे एक कदम आगे ले सकते हैं और संघर्षों को संपादित करने के लिए टोर्टोइज एसवीएन-जैसे इंटरफ़ेस को कार्यान्वित कर सकते हैं (यदि कोई है)।

इसके लिए कुछ यूआई प्रयास की आवश्यकता हो सकती है, लेकिन इसके परिणामस्वरूप समवर्ती संपादन की अनुमति देने का एक अच्छा तरीका होगा।

nice diff interface बनाने के उदाहरण के रूप में आप Rietveld में उपयोग किए गए HTML/JS/CSS कोड को देखना चाहेंगे।

संबंधित मुद्दे