2008-10-27 11 views
12

मेरे पास काम पर एक वेब एप्लिकेशन है जो टिकट कार्य प्रणाली के समान है। कुछ उपयोगकर्ता नए मुद्दे दर्ज करते हैं। अन्य कर्मचारी मुद्दों को चुनते हैं और हल करते हैं। एमएस एसक्यूएल सर्वर 2005 में सभी डेटा बनाए रखा जाता है।उपयोगकर्ताओं को उसी पंक्ति पर काम करने से रोकना

समस्याएं हल करने के लिए काम कर रहे उपयोगकर्ता ऐसे पृष्ठ पर जाते हैं जहां वे खुले मुद्दों को देख सकते हैं। क्योंकि बीस लोग एक ही समय में इस पृष्ठ को देख सकते हैं, मुझे एक संभावित समस्या का समाधान करना था, अगर कोई ऐसा मुद्दा उठाता है जो किसी और ने अपने पृष्ठ लोड होने के बाद उठाया है।

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

समस्या यह है कि इसका AJAX हिस्सा बहुत अधिक अपडेट भेज रहा है (यह वही है जो मैं मान रहा हूं) और यह पृष्ठ और डेटाबेस के प्रदर्शन को प्रभावित कर रहा है। इसके अलावा, अद्यतन हर दूसरे प्रदर्शन नहीं कर रहे हैं। संग्रहीत प्रक्रियाओं को ट्रिगर करने के लिए काम करते समय मुझे टाइमर अविश्वसनीय लगता है।

एक बेहतर तरीका होना चाहिए, लेकिन मुझे एक ऐसा प्रतीत नहीं होता है। क्या किसी को इस तरह की स्थिति के साथ अनुभव है या एकाधिक उपयोगकर्ताओं को बनाए रखने के लिए एक ही रिकॉर्ड का चयन करने के सुझाव हैं? मैं वास्तव में AJAX भाग को पूरी तरह से अक्षम नहीं करना चाहता क्योंकि मुझे लगता है कि अकेले संदेश एप्लिकेशन को उपयोग करने में निराशाजनक बना देगा।

धन्यवाद,

उत्तर

3

दो चीजें आपकी समस्या को कम करने में मदद कर सकती हैं।

सबसे पहले, चयन के बाद अधिसूचना कि आपके AJAX अद्यतन समय सीमा के बावजूद मामला लिया गया है।यहां तक ​​कि हर सेकेंड की जांच करने का मतलब यह नहीं है कि दो लोग एक ही मामले पर क्लिक नहीं कर सकते हैं, जिसे वे एक ही समय में समझते हैं। ऐसे मामलों में, उपयोगकर्ताओं में से एक को सूचित किया जाना चाहिए कि उनका चयन अमान्य है, भले ही यह चयनित होने पर मान्य दिखाई दे। इस अधिसूचना को विस्तारित करने की आवश्यकता नहीं है; एक प्रकाश रखते हुए, सहायक स्वर निराशा के प्रकाश में भी उपयोगकर्ता धारणा को बेहतर बना सकता है। और यदि आप उस उपयोगकर्ता को पहचानते हैं जिसने पहले से ही उस रिकॉर्ड को चुना है, तो यह न केवल भविष्य में आपके उपयोगकर्ताओं को समन्वयित करने में मदद करेगा बल्कि आपके कार्यक्रम से उस उपयोगकर्ता को भी ध्यान देगा जो रसदार मामले को छीन लेता है।

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

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

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

+0

+1, वास्तव में मैं सुझाव देने जा रहा था! –

+1

यादृच्छिक आदेश काम नहीं करेगा। टिकट स्तर की समाप्ति द्वारा टिकटों को प्राथमिकता दी जाती है। –

+1

सेवा स्तर की समाप्ति का आधार क्या है? क्या यह समय-आधारित निर्धारण है? आपके मुद्दे की गणना के आधार पर, आप उन्हें निकटतम मिनट (या पंद्रह मिनट) में समूहित करने में सक्षम हो सकते हैं और यह "पर्याप्त पर्याप्त" हो सकता है। वैसे भी, मुझे पता है कि प्राथमिकता के लिए अपवाद मांगना राजनीतिक रूप से समस्याग्रस्त हो सकता है, लेकिन यदि आप * कर सकते हैं, तो यह इसके लायक साबित हो सकता है। –

2

क्या आपने रीफ्रेश के बीच समय बढ़ाने की कोशिश की है। मैं उम्मीद करता हूं कि प्रति 30 सेकंड में एक बार पर्याप्त होगा। 40 अनुरोध/मिनट 1200/मिनट से बहुत कम भार है। आपके उपयोगकर्ता अंतर भी नहीं देख सकते हैं।

यदि वे करते हैं, तो पेज पर रीफ्रेश बटन प्रदान करने के बारे में, ताकि उपयोगकर्ता चुनने वाले परेशान संदेश से बचने के लिए किसी आइटम को चुनने से ठीक पहले सूची को रीफ्रेश कर सकें।

+0

मुझे लगता है कि इस तरह से उपयोग किया जाने वाला AJAX बिल्कुल अच्छा समाधान नहीं है - यह हर सेकेंड या हर 30 सेकंड हो। रीफ्रेश एक अच्छा विचार है। मैंने इसके बारे में सोचा नहीं है। ग्रिडव्यू के ऊपर एक छोटा सा लिंक अच्छी तरह से काम करेगा। फिर भी, यह इसकी कुछ उपयोगिता खो देता है। –

+0

मैं आमतौर पर उपयोगकर्ताओं को सूचित करने के लिए रीफ्रेश का उपयोग करता हूं जब नई जानकारी को थोड़ी देर के लिए नेविगेट नहीं किया गया है। हालांकि, मेरी ताज़ा दर 5 मिनट की तरह है। – tvanfosson

+0

अगर मुझे कुछ याद आ गया है तो मुझे सही करें, लेकिन ऐसा लगता है कि लॉक का उपयोग करने के बजाय 'नींद()' कॉल के साथ एक समेकन समस्या को हल करने की वकालत की तरह लगता है। यह समवर्ती संपादन के मुद्दे को हल नहीं करेगा, बस इसे मुखौटा करें। – asveikau

2

यदि संभव हो तो सिस्टम को सीमित करें ताकि वे कार्य कतार से अगले खुले मुद्दे को प्राप्त कर सकें क्योंकि उन्हें सभी खुले मुद्दों से चुनने में सक्षम होना चाहिए।

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

+0

दुर्भाग्य से, काम की प्रकृति के कारण, अगली कतार में सीमित एक विकल्प नहीं है। मुझे यह गायब होने का विचार पसंद है जब उपयोगकर्ता इसे पहले से चुना गया है, लेकिन मुझे चिंता है कि यह केवल उपयोगकर्ताओं को निराश करेगा। –

+0

मुझे लगता है कि संभावित उपयोगकर्ता निराशा एक बहुत ही वैध चिंता है। यदि आप इस मार्ग पर जाते हैं तो आप निश्चित रूप से उपयोगकर्ता स्वीकृति के लिए प्रोटोटाइप करना चाहते हैं। मुझे लगता है कि आप निश्चित रूप से उपयोगिता बनाम उपयोगिता के साथ एक तंग जगह में हैं। –

+0

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

4

डेटाबेस में पंक्ति पर एक लॉक टाइमस्टैम्प फ़ील्ड रखें। एक संग्रहित proc लिखें जो समाप्ति टाइमसेटैम्प किसी विशिष्ट समय से पुरानी हो तो सत्य या गलत लौटाती है। एक ही समय में एक या दो मिनट में समाप्त होने के लिए अपने सत्रों को अपने वेब ऐप पर सेट करें। जब कोई उपयोगकर्ता एक पंक्ति का चयन करता है तो वे संग्रहीत प्रोसेस को हिट करते हैं जो ऐप को यह तय करने में सहायता करता है कि क्या इसे उपयोगकर्ता को इसे संशोधित करने देना चाहिए।

आशा है कि समझ में आता है ....

+0

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

+0

ठीक है, सर्वर पर पोस्टबैक नहीं होने पर आप उन्हें कैसे छुपा सकते हैं? –

+0

AJAX कुछ jquery baby – craigmoliver

3

मैं कुछ इसी तरह जहां एक बार एक उपयोगकर्ता एक टिकट (पंक्ति) खोला किया यह है कि उपयोगकर्ता के लिए कि टिकट सौंपा और कहा कि रिकॉर्ड पर एक मूल्य सेट की गई FK की तरह और, विशेष उपयोगकर्ता, इसलिए अगर किसी और ने उस टिकट (पंक्ति) को खोलने की कोशिश की तो यह उन्हें बताएगा कि इसे किसी और को सौंपा गया है।

+0

यह वास्तव में हम जो कर रहे हैं उसका एक टुकड़ा है। हम इस मुद्दे के स्टेटस कोड को इंगित करने के लिए बदलते हैं कि यह बनाए रखा जा रहा है। हम लगातार एक टाइमस्टैम्प अपडेट करते हैं जो इस स्थिति में रिकॉर्ड को तब तक रखता है जब तक इसे अपडेट किया जा रहा हो। यह अकेले ही उपयोगकर्ता ऐसे रिकॉर्ड चुनने वाले होंगे जो वे काम नहीं कर सकते हैं। यादृच्छिकरण के लिए –

1

मुझे इस मुद्दे को देखने में कोई कमी नहीं है, विशेष रूप से जब आप उल्लेख करते हैं कि आप पहले से ही प्रगति/रखरखाव के रूप में टिकटों को फ़्लैग कर रहे हैं और आइटम का टाइमस्टैम्प/संस्करण है।

है नहीं पर्याप्त निम्नलिखित:

  1. उपयोगकर्ता टिकट ब्राउज़ करता और टिकट उपलब्ध यानी यह जो कि प्रगति पर के रूप DB में हैं शामिल नहीं है की एक सूची देखता है। यदि आप चाहते हैं कि उपयोगकर्ता प्रगति पर टिकट भी देखें, तो आप इसे टिकट की स्थिति में स्पष्ट रूप से इंगित करते हैं और इसे लेने के विकल्प को अक्षम करते हैं।
  2. उपयोगकर्ता या तो टिकट खोलकर स्पष्ट रूप से या स्पष्ट रूप से प्रगति के रूप में टिकट चलाता है (उपयोगकर्ता अनुभव/उपयोगकर्ताओं को प्रस्तुत करने पर निर्भर करता है)।
  3. उपयोगकर्ता स्पष्ट रूप से कोई दूसरी स्थिति अर्थात पूरा, अवैध, प्रतिक्रिया के लिए इंतजार कर रहा है, आदि

टिकट ले जाता है आइटम 1 में प्राप्त किए गए हैं, तो आप एक टाइमस्टैम्प/संस्करण शामिल हैं। जब 2 होता है, तो आप यह सुनिश्चित करने के लिए आशावादी समेकन दृष्टिकोण का उपयोग करते हैं कि यदि 2 व्यक्ति एक ही समय में टिकट लेने का प्रयास करते हैं तो केवल पहला सफल होगा।

क्या होगा यह होगा कि दूसरे व्यक्ति के लिए, अद्यतन ... कहां ... timestamp = @timestamp को अपडेट करने के लिए कोई रिकॉर्ड नहीं मिलेगा और आप वापस रिपोर्ट करेंगे कि टिकट पहले से ही लिया गया था।

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

+0

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

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