दस्तावेज़ सर्वर: समवर्ती बचत को संभालना

मैं एक दस्तावेज़ सर्वर लागू कर रहा हूँ। वर्तमान में, यदि दो उपयोगकर्ता एक ही दस्तावेज़ खोलते हैं, तो इसे संशोधित करें और परिवर्तनों को सहेजें, दस्तावेज़ का राज्य अपरिभाषित होगा (या तो पहले उपयोगकर्ता के परिवर्तन स्थायी रूप से सहेजे जाते हैं, या दूसरे का)। यह पूरी तरह असंतोषजनक है। मैंने इस समस्या को हल करने के लिए दो संभावनाएं मानीं:

The first is to lock the document when it is opened by someone the first time, and unlock it when it is closed. But if the network connection to the server is suddenly interrupted, the document would stay in a forever-locked state. The obvious solution is to send regular pings to the server. If the server doesn't receive K pings in a row (K > 1) from a particular client, documents locked by this client are unlocked. If that client re-appears, documents are locked again, if someone hadn't already locked them. This could also help if the client application (running in web browser) is terminated unexpectedly, making it impossible to send a 'quitting, unlock my documents' signal to the server.

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

मुझे यह समझने के लिए क्या विधि चुननी चाहिए कि सर्वर से कनेक्शन कभी-कभी धीमा और अनुत्तरदायी हो सकता है? पैरामीटर (पिंग अंतराल, तेजी से उत्तराधिकार अंतराल) कैसे निर्धारित किया जाना चाहिए?

अनुलेख दुर्भाग्यवश, मैं डेटाबेस में दस्तावेज़ों को संग्रहीत नहीं कर सकता।

0
ro fr bn

3 उत्तर

मेरा सुझाव आपके पहले की तरह कुछ होगा। जब पहला उपयोगकर्ता (बॉब) दस्तावेज़ खोलता है, तो वह लॉक प्राप्त करता है ताकि अन्य उपयोगकर्ता केवल वर्तमान दस्तावेज़ को पढ़ सकें। यदि उपयोगकर्ता इसका उपयोग करते समय दस्तावेज़ सहेजता है, तो वह ताला रखता है। केवल जब वह दस्तावेज़ से बाहर निकलता है, तो यह अनलॉक हो जाता है और अन्य लोग इसे संपादित कर सकते हैं।

यदि दूसरा उपयोगकर्ता (केट) दस्तावेज खोलता है, जबकि बॉब के पास लॉक है, तो केट को यह संदेश मिलेगा कि दस्तावेज़ अयोग्य है लेकिन जब तक इसे लॉक जारी नहीं किया जाता है तब तक वह इसे पढ़ सकती है।

तो जब बॉब लॉक प्राप्त करता है तो क्या होता है, शायद दस्तावेज़ को एक या दो बार बचाता है लेकिन फिर लॉक फांसी छोड़ने वाले एप्लिकेशन से बाहर निकलता है?

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

एक पिंग में उस दस्तावेज़ का नाम हो सकता है जिस पर क्लाइंट का लॉक चालू होता है, और सर्वर उस गणना के लिए अंतिम पिंग प्राप्त होने पर गणना कर सकता है।

0
जोड़ा

वर्तमान में दस्तावेज़ लोगों के सीमित समूह द्वारा प्रकाशित किए जाते हैं, उनमें से प्रत्येक एक अलग विषय पर काम कर रहे हैं। तो, ताले से शुरू असुविधा कम हो गई है। लोग ज्यादातर मौजूदा दस्तावेजों का विस्तार करते हैं और उनमें गलतियों को सही करते हैं।

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

अब आशावादी मॉडल पर विचार करें। यदि दस्तावेज़ों में कुछ नियमित (कहें, पदानुक्रमित) संरचना है, तो मतभेदों का पता कैसे लगाया जाना चाहिए? अगर नहीं? इन मामलों में सफल स्वचालित विलय की संभावना क्या है?

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

तुम क्या सोचते हो?

0
जोड़ा

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

विवाद को मानना ​​अपेक्षाकृत कम है और/या प्रत्येक परिवर्तन का आकार काफी छोटा है, तो शायद मैं एक आशावादी मॉडल का चयन करूंगा जो स्वचालित या मैन्युअल विलय का उपयोग करके संघर्ष को हल करता है। किसी संस्करण संख्या या दस्तावेज की सामग्री का चेकसम का उपयोग यह निर्धारित करने के लिए किया जा सकता है कि एक मर्ज आवश्यक है या नहीं।

0
जोड़ा