2012-04-04 14 views
15

से कॉलिंग कॉन्फ़िगरएवेट कॉलिंग मैं प्रेजेंटेशन पर काम कर रहा था और सोचा कि निम्नलिखित विफल होना चाहिए क्योंकि सही संदर्भ पर ActionResult वापस नहीं किया जा रहा है। मैंने इसे वीएस के साथ परीक्षण किया है और इसमें कोई त्रुटि नहीं है। मैंने इसे डीबग किया है और पता है कि यह थ्रेड स्विच कर रहा है। तो ऐसा लगता है कि यह कानूनी कोड है।एएसपी.नेट एमवीसी एक्शन

क्या एएसपी.NET परवाह नहीं है कि क्लाइंट ऐप की तरह यह संदर्भ या धागा क्या है? यदि हां, तो AspNetSynchronizationContext क्या उद्देश्य प्रदान करता है? मुझे एक्शन में कॉन्फ़िगरएवेट डालने का अधिकार नहीं है। इसके बारे में कुछ गलत लगता है। क्या कोई समझा सकता है?

public async Task<ActionResult> AsyncWithBackendTest() 
    { 
     var result = await BackendCall().ConfigureAwait(false); 
     var server = HttpContext.Server; 
     HttpContext.Cache["hello"] = "world"; 
     return Content(result); 
    } 
+2

एक सही उत्तर या तो कहना चाहिए कि ऐसा क्यों करना बिल्कुल ठीक है या जब आप इसे आजमाते हैं तो क्या विफल हो जाता है इसका एक उदाहरण देना चाहिए।मेरा आंत मुझे बताता है कि मुझे नहीं करना चाहिए, लेकिन मैं मुझे वापस लेने के लिए तथ्यों को देखना चाहता हूं। –

उत्तर

6

ASP.NET 'यूआई धागा' नहीं है जरूरत है कि कई ग्राहकों क्षुधा (इसके नीचे यूआई ढांचे की वजह से) है। इस संदर्भ धागा आत्मीयता के बारे में नहीं है, लेकिन पेज प्रगति ट्रैकिंग (और अन्य चीजें हैं, अनुरोध के लिए सुरक्षा संदर्भ चारों ओर ले जाने की तरह)

Stephen Toub mentions this in an MSDN article के लिए:

विण्डोज़ फॉर्म्स केवल वातावरण नहीं है जो सिंक्रनाइज़ेशन कॉन्टेक्स्ट-व्युत्पन्न क्लास प्रदान करता है। एएसपी.नेट भी एक, एएसपीनेट सिंक्रनाइज़ेशन कॉन्टेक्स्ट प्रदान करता है, हालांकि यह सार्वजनिक नहीं है और बाहरी खपत के लिए नहीं है। इसके बजाय, इसका उपयोग A12.NET 2.0 में एसिंक्रोनस पेज कार्यक्षमता को सुविधाजनक बनाने के लिए एएसपी.NET द्वारा कवर के तहत किया जाता है (अधिक जानकारी के लिए, msdn.microsoft.com/msdnmag/issues/05/10/WickedCode देखें)। यह कार्यान्वयन एएसपी.NET को पृष्ठ प्रसंस्करण पूर्णता को रोकने के लिए अनुमति देता है जब तक कि सभी बकाया एसिंक्रोनस इनवॉशंस पूरा नहीं हो जाते हैं।

सिंक्रनाइज़ेशन संदर्भ के बारे में थोड़ा और विवरण Stephen Cleary's article from last year में दिया गया है।

विशेष रूप से चित्रा 4 में दिखाता है कि इसमें WinForms/WPF का 'विशिष्ट धागा' व्यवहार नहीं है, लेकिन पूरी बात एक अच्छी पढ़ाई है।

यदि एक से अधिक आपरेशन पूरा एक ही आवेदन के लिए एक ही बार में, AspNetSynchronizationContext यह सुनिश्चित करेंगे कि वे एक बार में एक ही निष्पादित। वे किसी भी धागे पर निष्पादित हो सकते हैं, लेकिन उस धागे में मूल पृष्ठ की पहचान और संस्कृति होगी।

+0

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

4

आपके कोड में, HttpContext आपके AsyncController बेस क्लास का सदस्य है। यह निष्पादन धागे के लिए वर्तमान संदर्भ नहीं है।

इसके अलावा, आपके मामले में, HttpContext अभी भी मान्य है, क्योंकि अनुरोध अभी तक पूरा नहीं हुआ है।

मैं इस समय परीक्षण करने में असमर्थ हूं, लेकिन अगर आप HttpContext के बजाय System.Web.HttpContext.Current का उपयोग करते हैं तो मैं असफल होने की उम्मीद करूंगा।

पीएस सुरक्षा हमेशा प्रचारित है, ConfigureAwait पर ध्यान दिए बिना - यदि आप इसके बारे में सोचते हैं तो यह समझ में आता है। मुझे संस्कृति के बारे में निश्चित नहीं है, लेकिन अगर मैं हमेशा प्रचारित होता तो मुझे आश्चर्य नहीं होगा।

+0

हाँ, मेरे चर हमेशा वैध होंगे क्योंकि वे केवल ढेर में लपेट गए हैं। लेकिन यहां तक ​​कि System.Web.HttpContext.Current अभी भी वैध और सही डेटा है। –

+0

क्या 'बैकएंडकॉल' समकालिक रूप से लौट रहा है? –

+0

नहीं। लॉजिकल चेक के अलावा, मैंने इसे डीबग किया है और इसे थ्रेड स्विच किया है। –

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