jsf

Question

में BusyConversationException से कैसे बचें, मुझे अपने जेएसएफ प्रोजेक्ट में पृष्ठों के माध्यम से नेविगेट करते समय व्यस्त कॉन्फ़्रेंसेशन अपवाद प्राप्त हो रहा है। यह तब होता है जब उपयोगकर्ता AJAX कॉल के दौरान किसी अन्य पृष्ठ पर नेविगेट करने का प्रयास करता है। यह तब भी होता है जब उपयोगकर्ता पृष्ठ को लोड करने की प्रतीक्षा किए बिना किसी अन्य लिंक पर क्लिक करने के बाद दाईं ओर एक लिंक पर क्लिक करता है।

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

<h:commandLink value="#{theProfile.profileName}" 
       title="#{theProfile.profileName}" 
       action="#{profileBean.aProfileSelected}"> 
       <f:setPropertyActionListener target="#{currentProfileWebBean.theProfile}" value="#{theProfile}"/> 
</h:commandLink> 

मैं एक ExceptionHandler वर्ग जो ExceptionHandlerWrapper वर्ग फैली लेकिन मैं अपने वर्तमान स्थिति और सबसे अच्छा मैं इस मामले के लिए क्या कर सकते हैं मुख्य पृष्ठ पर रीडायरेक्ट करने के लिए जब यह अपवाद तब होता है नहीं बचा सकते में अपवाद के इस प्रकार पकड़ कर सकते हैं ।

क्या इससे बचने के लिए कोई समाधान है? उत्तर और टिप्पणियों के लिए अग्रिम धन्यवाद।

Answer 1

अन्य उत्तर में उल्लेख किया है, ऐसा होता है, तो एक ajax अनुरोध अभी भी जमा करने commandLink पर कार्रवाई की जा रही है या एक ajax घटना वास्तविक क्लिक करने से पहले शुरू हो रहा है, तो नहीं मिल रहा है या कमांड बटन (उदाहरण के लिए इनपुट फ़ील्ड पर एक परिवर्तन घटना द्वारा)।

Therfore यह संभव नहींonclick="preventEventPropagation(event)"; साथ BusyConversationExceptions से बचने के लिए के बाद से AJAX घटनाओं प्रचार के माध्यम से ट्रिगर नहीं होते है।

अजाक्स अनुरोधों को चलाने और लंबित AJAX ईवेंट पूरा होने तक सबमिट को अवरुद्ध करके समस्या को आसानी से टाला जा सकता है।

इस ब्लॉग पोस्ट JSF2 AJAX/Submit conversation issue में समस्या और समाधान को और विस्तार से समझाया गया है।

Answer 2

मैं इसे कभी-कभी देख रहा हूं। मैं इसे एक अच्छा विचार है बातचीत के लिए serializing पहुँच में कुछ प्रयास डाल करने के लिए सोचने के लिए शुरू कर रहा हूँ:

1. बचें बातचीत ID (CID) जब आप लक्ष्य को देखने के लिए कि बातचीत उदाहरण की जरूरत नहीं है प्रचार। विशेष रूप से, असंबंधित नेविगेशन लिंक/बटन को सिड पैरामीटर को दबाना चाहिए (
2. सक्रिय बातचीत का उपयोग करने वाले अनुरोध को प्रारंभ करते समय, वार्तालाप प्रसारित करने वाले अन्य UI तत्वों को अक्षम करें और इसलिए समवर्ती कारण हो सकते हैं पहुंच। प्राइमफेस या (यहां तक ​​कि बेहतर) प्राइमफेस एक्सटेंशंस ब्लॉकयूआई घटक प्राइमफेस पी के साथ एक पारदर्शी ओवरले के रूप में अच्छी तरह से काम करते हैं: व्यस्त स्थिति दिखाने के लिए AJAXStatus।
3. जितनी देर हो सके बातचीत शुरू करें। इससे उन मामलों को कम किया जाएगा जहां एक लंबी चल रही बातचीत का प्रचार किया जाएगा।

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

Answer 3

मैं इस पाया,

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

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

here

Answer 4

मैं भी एक ही समस्या का सामना करना पड़ा जब मैं क्लिक करने के लिए प्रयोग किया जाता का संदर्भ लें।

मैंने पुस्तक में से एक में पढ़ा है, व्यस्त घटनाएं उस घटना के साथ होती हैं, दो क्रियाएं हो रही हैं, इसलिए उन्होंने उपयोग किया: onclick="preventEventPropagation(event)"; कमांड लिंक में उस क्लिक के ईवेंट प्रसार को रोकने के लिए।तो मैंने इसका इस्तेमाल किया है और यह मेरे लिए काम कर रहा है।

तो अब BusyConversationException :)