2009-11-14 7 views
15

सत्र सक्रिय होने पर मैं एक समय में एक से अधिक अनुरोध करने में सक्षम नहीं हूं। यह सीमा क्यों मौजूद है? क्या इसके आसपास काम करने का कोई तरीका है?क्या एक एएसपीनेट उपयोगकर्ता एक समय में एक से अधिक अनुरोध कर सकता है यदि सत्र उपयोग में है?

यह समस्या वेबफॉर्म ऐप के साथ केवल 3 सरल एएसपीएक्स पृष्ठों के साथ प्रदर्शित की जा सकती है (हालांकि सीमा अभी भी एएसपीएनटी एमवीसी में लागू होती है)।

एएसपीनेट 3.5 वेब एप्लिकेशन बनाएं।

सिर्फ तीन पृष्ठों होनी चाहिए: NoWait.aspx, Wait.aspx, और SessionStart.aspx

NoWait.aspx है इस एक डला डिफ़ॉल्ट div टैग के बीच कहा: <% = DateTime.Now.Ticks %>। इस पृष्ठ के लिए कोड-बैक डिफ़ॉल्ट (खाली) है।

Wait.aspx NoWait.aspx की तरह दिखता है, लेकिन इसमें कोड-पीछे में पेज_लोड में एक पंक्ति जोड़ा गया है: थ्रेड। सो (3000); // प्रतीक्षा 3 सेकंड

सत्रस्टार्ट.एएसएक्स भी NoWait.aspx की तरह दिखता है, लेकिन इसकी कोड में इसके पीछे एक पंक्ति है: सत्र ["जो भी"] = "कुछ भी";

ब्राउज़र खोलें और NoWait.aspx पर जाएं। यह प्रतिक्रिया में एक संख्या ठीक से दिखाता है, जैसे: "633937963004391610"। ताज़ा रहें और यह संख्या बदलता रहता है। अब तक बहुत बढ़िया! उसी ब्राउज़र में एक नया टैब बनाएं और Wait.aspx पर जाएं। यह 3 सेकंड के लिए बैठता है, फिर प्रतिक्रिया के लिए संख्या लिखता है। अब तक बहुत बढ़िया! नहीं, इसे आज़माएं: Wait.aspx पर जाएं और कताई के दौरान, जल्दी से NoWait.aspx पर टैब करें और रीफ्रेश करें। यहां तक ​​कि Wait.aspx सो रहा है, NoWait.aspx एक प्रतिक्रिया प्रदान करेगा। अब तक बहुत बढ़िया Wait.aspx कताई है, जबकि आप NoWait.aspx को रीफ्रेश करना जारी रख सकते हैं, और सर्वर हर बार खुशी से प्रतिक्रिया भेजता है। यह वह व्यवहार है जो मैं उम्मीद करता हूं।

अब यह अजीब हो जाता है।

एक ही टैब में, एक ही टैब में, सत्रस्टार्ट.aspx पर जाएं। अगला, प्रतीक्षा करें .aspx पर रीफ्रेश करें और रीफ्रेश करें। कताई के दौरान, NoWait.aspx पर टैब और रीफ्रेश करें। NoWait.aspx प्रतीक्षा नहीं करेगा जब तक Wait.aspx चल रहा है!

यह साबित करता है कि एक सत्र सक्रिय होने पर, आप एक ही उपयोगकर्ता के साथ समवर्ती अनुरोध नहीं कर सकते हैं। अनुरोध सभी कतारबद्ध हैं और समकालिक रूप से परोसे जाते हैं। मुझे इस व्यवहार की उम्मीद या समझ नहीं है। मैंने विजुअल स्टूडियो 2008 के वेब सर्वर में निर्मित, और आईआईएस 7 और आईआईएस 7.5 पर इसका परीक्षण किया है।

तो मैं कुछ प्रश्न हैं:

1) मैं सही हूँ यहाँ वास्तव में एक सीमा है वहाँ, या अमान्य ऊपर अपने परीक्षण क्योंकि मैंने कुछ गलत कर रहा हूँ है?

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

3) यह सीमा क्यों मौजूद है? मैं इस बारे में अच्छी समझ हासिल करना चाहता हूं कि यह सीमा क्यों जरूरी है। मुझे लगता है कि अगर मैं जानता था तो मैं एक बेहतर डेवलपर बनूंगा!

उत्तर

11

Here is a link talking about session state and locking. यह निष्पादन और अनन्य लॉक करता है।

इसके आसपास का सबसे आसान तरीका लंबे समय तक चलने वाले कार्यों को अतुल्यकालिक बनाना है।आप लंबे समय तक चलने वाले कार्यों को एक अलग थ्रेड पर चला सकते हैं, या asynchronous delegate का उपयोग कर सकते हैं और तुरंत ब्राउज़र पर प्रतिक्रिया दे सकते हैं। क्लाइंट साइड पेज सर्वर को अनुरोध भेज सकता है कि यह किया गया है और यह देखने के लिए कि क्या यह किया जाता है (AJAX सबसे अधिक संभावना के माध्यम से), और जब सर्वर क्लाइंट को बताता है कि यह समाप्त हो गया है, तो उपयोगकर्ता को सूचित करें। इस तरह से सर्वर अनुरोधों को सर्वर द्वारा एक समय में संभाला जाना है, यह उपयोगकर्ता की तरह दिखता नहीं है।

इसमें यह समस्याएं हैं, और आपको यह सुनिश्चित करना होगा कि HTTP संदर्भ के लिए खाता बंद हो रहा है क्योंकि यह asp.net सत्र में कुछ कार्यक्षमता का निपटान करेगा। एक उदाहरण जो आपको शायद खाते में रखना होगा, शायद यह वास्तव में होने पर सत्र पर लॉक जारी कर रहा है।

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

+0

और वहां हमारे पास है। मैंने आज पहले उस पृष्ठ की जांच की लेकिन मैंने पूरी बात नहीं पढ़ी। समवर्ती मुद्दा बहुत अंतिम अनुच्छेद है! लिंक के लिए धन्यवाद! – Chris

9

केविन ने वर्णित कारणों से, उपयोगकर्ता दो तक नहीं पहुंच सकते वे पृष्ठ जो एक ही समय में अपने सत्र स्थिति में लिख सकते हैं - ढांचा स्वयं सत्र स्टोर के लॉकिंग पर जुर्माना नियंत्रण नहीं लगा सकता है, इसलिए इसे पूरे अनुरोधों के लिए लॉक करना होगा।

इस के आसपास काम करने के लिए, केवल पढ़ने वाले पृष्ठ सत्र डेटा घोषित कर सकते हैं कि वे ऐसा करते हैं। एएसपी.नेट को उनके लिए एक सत्र राज्य लिखने का लॉक नहीं मिलेगा:

// Or false if it doesn't need access to session state at all 
EnableSessionState="ReadOnly" 
संबंधित मुद्दे

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