मुझे अभी पता चला है कि सभी ASP.Net वेबसाइट्स धीमी क्यों हैं, और मैं इस बारे में काम करने की कोशिश कर रहा हूं कि इसके बारे में क्या करना है

Question

मुझे अभी पता चला है कि ASP.Net वेब एप्लिकेशन में प्रत्येक अनुरोध एक अनुरोध की शुरुआत में एक सत्र लॉक हो जाता है, और फिर अनुरोध के अंत में इसे जारी करता है!

इस मामले में निहितार्थ आप पर खो गए हैं, क्योंकि यह मेरे लिए पहले था, इसका मूल रूप से निम्नलिखित अर्थ है:

• कभी भी ASP.Net वेबपेज को लोड होने में लंबा समय लग रहा है (हो सकता है कि धीमे डेटाबेस कॉल या जो भी हो) के कारण, और उपयोगकर्ता तय करता है कि वे एक अलग पेज पर नेविगेट करना चाहते हैं क्योंकि वे प्रतीक्षा करते-करते थक गए हैं, तो वे नहीं कर सकते! ASP.Net सत्र लॉक नए पेज के अनुरोध को प्रतीक्षा करने के लिए मजबूर करता है जब तक कि मूल अनुरोध ने इसकी धीमी गति से लोड को समाप्त नहीं किया है। Arrrgh।

• जब भी कोई UpdatePanel धीरे-धीरे लोड हो रहा है, और उपयोगकर्ता UpdatePanel को अपडेट करने से पहले एक अलग पृष्ठ पर नेविगेट करने का निर्णय लेता है ... वे नहीं कर सकते! ASP.net सत्र लॉक नए पेज के अनुरोध को तब तक इंतजार करने के लिए मजबूर करता है जब तक कि मूल अनुरोध ने इसकी धीमी गति से लोड को समाप्त नहीं कर दिया हो। डबल Arrrgh!

तो, विकल्प क्या हैं? अब तक मैं साथ आया हूँ:

• एक कस्टम SessionStateDataStore लागू करें, जो ASP.Net का समर्थन करता है। मुझे कॉपी करने के लिए बहुत सारे नहीं मिले हैं, और यह उच्च जोखिम और गड़बड़ करने में आसान लगता है।
• प्रगति के सभी अनुरोधों पर नज़र रखें, और यदि एक अनुरोध एक ही उपयोगकर्ता से आता है, तो मूल अनुरोध को रद्द करें। अति की तरह लगता है, लेकिन यह काम करेगा (मुझे लगता है)।
• सत्र का उपयोग न करें! जब मुझे उपयोगकर्ता के लिए किसी प्रकार की स्थिति की आवश्यकता होती है, तो मैं इसके बजाय कैश का उपयोग कर सकता हूं, और प्रमाणित उपयोगकर्ता नाम या कुछ ऐसी चीजों पर कुंजी आइटम। फिर से चरम की तरह लगता है।

मैं वास्तव में विश्वास नहीं कर सकता कि ASP.Net Microsoft टीम ने संस्करण 4.0 में फ्रेमवर्क में इतना बड़ा प्रदर्शन अड़चन छोड़ दिया होगा! क्या मुझसे साफ़ - साफ़ कुछ चीज़ चूक रही है? सत्र के लिए थ्रेडसेफ़ संग्रह का उपयोग करना कितना कठिन होगा?

Comments

आपको पता चलता है कि यह साइट .NET .NET से निर्मित है। उस ने कहा, मुझे लगता है कि यह बहुत अच्छी तरह से तराजू है।

— गेहूं

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

— जेम्स

एमवीसी के नजरिए से इस पर अनुच्छेद

— २३:३२ पर १५'१२

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

— ars265

@ ars265 - जोएल मुलर ने बहुत सारी अच्छी जानकारी दी, और मैं उसके लिए उन्हें धन्यवाद देना चाहता था। हालाँकि, मैं अंततः अपने पोस्ट में सुझाए गए रास्ते से अलग रास्ते से गया था। इसलिए, उत्तर के रूप में एक अलग पोस्ट को चिह्नित करना।

— जेम्स

Answer 1

यदि आपका पृष्ठ किसी भी सत्र चर को संशोधित नहीं करता है, तो आप इस लॉक से बाहर निकल सकते हैं।

<% @Page EnableSessionState="ReadOnly" %>

यदि आपका पृष्ठ किसी भी सत्र चर को नहीं पढ़ता है, तो आप उस पृष्ठ के लिए, इस लॉक से पूरी तरह से बाहर निकल सकते हैं।

<% @Page EnableSessionState="False" %>

यदि आपका कोई भी पृष्ठ सत्र चर का उपयोग नहीं करता है, तो web.config में सत्र स्थिति को बंद कर दें।

<sessionState mode="Off" />

मैं उत्सुक हूं, आपको क्या लगता है कि "थ्रेडसेफ़ संग्रह" थ्रेड-सुरक्षित होने के लिए क्या करेगा, अगर यह ताले का उपयोग नहीं करता है?

संपादित करें: मुझे शायद इस बात से समझाना चाहिए कि "अधिकांश इस लॉक से बाहर निकलें" से मेरा क्या मतलब है। एक-दूसरे को अवरुद्ध किए बिना एक ही समय में दिए गए सत्र के लिए किसी भी संख्या में केवल-रीड-सेशन या नो-सेशन पेज संसाधित किए जा सकते हैं। हालाँकि, एक रीड-राइट-सेशन पेज तब तक प्रोसेसिंग शुरू नहीं कर सकता, जब तक कि सभी रीड-ओनली रिक्वेस्ट पूरी नहीं हो जाती हैं, और जब यह चल रहा होता है, तो उस यूजर के सेशन में एक्सक्लूसिव एक्सेस होना चाहिए ताकि स्थिरता बनी रहे। व्यक्तिगत मूल्यों पर ताला लगाने से काम नहीं चलेगा, क्योंकि क्या होगा अगर एक पृष्ठ एक समूह के रूप में संबंधित मूल्यों का एक सेट बदल दे? आप यह कैसे सुनिश्चित करेंगे कि एक ही समय में चलने वाले अन्य पृष्ठों को उपयोगकर्ता के सत्र चर का एक सुसंगत दृश्य मिलेगा?

मेरा सुझाव है कि यदि संभव हो तो एक बार सेट होने के बाद आप सत्र चर को संशोधित करने का प्रयास करें। यह आपको अपने पृष्ठों के अधिकांश हिस्से को केवल-पढ़ने वाले सत्रों के पृष्ठ बनाने की अनुमति देगा, जिससे यह मौका बढ़ेगा कि एक ही उपयोगकर्ता से एक साथ कई अनुरोध एक-दूसरे को अवरुद्ध नहीं करेंगे।

Comments

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

— जेम्स

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

— जोएल मुलर

तो एक ऐसी प्रणाली विकसित करें जो सबसे कम आम भाजक प्रोग्रामर को पूरा करती है जो लॉकिंग का पता नहीं लगा सकता है? क्या आईआईएस उदाहरणों के बीच एक सत्र स्टोर साझा करने वाले वेब फ़ार्म को सक्षम करने का उद्देश्य है? क्या आप किसी ऐसी चीज का उदाहरण दे सकते हैं जिसे आप सत्र चर में संग्रहित करेंगे? मैं कुछ भी नहीं सोच सकता।

— जेसन गोएमाट

हां, यह एक उद्देश्य है। लोड संतुलन और अतिरेक के बुनियादी ढांचे में लागू होने पर विभिन्न परिदृश्यों को पुनर्विचार करें। जब उपयोगकर्ता वेबपेज पर काम करता है, अर्थात वह फॉर्म में डेटा दर्ज कर रहा है, तो मान लें, 5 मिनट, और वेबफ्रेम क्रैश में कुछ - एक नोड का पॉवर सोर्स पफ हो जाता है - उपयोगकर्ता को इस पर ध्यान नहीं देना चाहिए। उसे सत्र से बाहर नहीं निकाला जा सकता है क्योंकि उसका सत्र खो गया था, सिर्फ इसलिए कि उसके कार्यकर्ता अब मौजूद नहीं हैं। इसका मतलब है कि सही संतुलन / अतिरेक को संभालने के लिए, सत्रों को कार्यकर्ता नोड्स से हटा दिया जाना चाहिए ..

— quetzalcoatl

ऑप्ट-आउट का एक अन्य उपयोगी स्तर <pages enableSessionState="ReadOnly" />web.config में है और केवल विशिष्ट पृष्ठों पर लिखने में सक्षम करने के लिए @ पेज का उपयोग करें।

— MattW

Answer 2

ठीक है, अपने सभी इनपुट के लिए जोएल मुलर को इतना बड़ा सहारा। मेरा अंतिम समाधान इस MSDN लेख के अंत में कस्टम SessionStateModule का उपयोग करना था:

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

यह था:

• लागू करने के लिए बहुत जल्दी (वास्तव में प्रदाता मार्ग जाने से आसान लग रहा था)
• बॉक्स से बाहर (SessionStateUtility वर्ग के माध्यम से) ASP.Net सत्र के मानक का बहुत उपयोग किया गया

इसने हमारे आवेदन के लिए "स्नैपपन" की भावना को एक बड़ा अंतर बना दिया है। मुझे अभी भी विश्वास नहीं हो रहा है कि ASP.Net सत्र का कस्टम कार्यान्वयन पूरे अनुरोध के लिए सत्र को बंद कर देगा। यह वेबसाइटों के लिए सुस्ती का इतना बड़ा हिस्सा जोड़ता है। ऑनलाइन शोध की मात्रा को देखते हुए मुझे (और कई वास्तव में अनुभवी ASP.Net डेवलपर्स के साथ बातचीत) करना पड़ा, बहुत से लोगों ने इस मुद्दे का अनुभव किया है, लेकिन बहुत कम लोग कभी इस कारण की तह तक गए हैं। शायद मैं स्कॉट गु को एक पत्र लिखूंगा ...

मुझे आशा है कि यह कुछ लोगों को वहां से बाहर निकालने में मदद करता है!

Comments

यह संदर्भ एक दिलचस्प खोज है, लेकिन मुझे आपको कुछ चीजों के बारे में सावधानी बरतनी चाहिए - नमूना कोड में कुछ समस्याएं हैं: सबसे पहले, ReaderWriterLockइसके पक्ष में पदावनत किया गया है ReaderWriterLockSlim- आपको इसके बजाय इसका उपयोग करना चाहिए। दूसरा, lock (typeof(...))पदावनत भी कर दिया गया है - आपको निजी स्थिर ऑब्जेक्ट उदाहरण पर लॉक करना चाहिए। तीसरा, वाक्यांश "यह एप्लिकेशन एक ही सत्र पहचानकर्ता का उपयोग करने से वेब अनुरोधों को एक साथ नहीं रोकता है" एक चेतावनी है, एक विशेषता नहीं है।

— जोएल मुलर

मुझे लगता है कि आप यह काम कर सकते हैं, लेकिन आपको SessionStateItemCollectionनमूना कोड के उपयोग को थ्रेड-सेफ क्लास (शायद आधारित ConcurrentDictionary) के साथ बदलना होगा यदि आप लोड के तहत मुश्किल-से-पुन: उत्पन्न त्रुटियों से बचना चाहते हैं।

— जोएल मुलर

मैंने अभी इसे थोड़ा और अधिक देखा, और दुर्भाग्य ISessionStateItemCollectionसे Keysसंपत्ति के प्रकार की आवश्यकता है System.Collections.Specialized.NameObjectCollectionBase.KeysCollection- जिसका कोई सार्वजनिक निर्माता नहीं है। जी, धन्यवाद दोस्तों। यह बहुत सुविधाजनक है।

— जोएल मुलर

ठीक है, मेरा मानना ​​है कि मेरे पास आखिरकार एक पूर्ण सूत्र है, गैर-सत्र लॉकिंग सत्र का काम करना। अंतिम चरणों में एक कस्टम थ्रेडसेफ़ सेशनस्टैटेइम संग्रह लागू करना शामिल था, जो कि उपरोक्त टिप्पणी से जुड़े एमडीएसएन लेख पर आधारित था। इसके साथ पहेली का अंतिम टुकड़ा इस महान लेख पर आधारित थ्रेडसेफ़ एन्यूमरेटर बना रहा था: codeproject.com/KB/cs/safe_enumerable.aspx ।

— जेम्स

जेम्स - जाहिर है कि यह काफी पुराना विषय है, लेकिन मैं सोच रहा था कि क्या आप अपने अंतिम समाधान को साझा करने में सक्षम थे? मैंने ऊपर टिप्पणियों के धागे का उपयोग करने के साथ पालन करने की कोशिश की है, लेकिन अभी तक एक कार्य समाधान प्राप्त करने में सक्षम नहीं है। मैं काफी हद तक निश्चित हूं कि सत्र के सीमित उपयोग में कुछ भी मौलिक नहीं है जिसे लॉक करने की आवश्यकता होगी।

— bsiegel

Answer 3

मैंने AngiesList.Redis.RedisSessionStateModule का उपयोग करना शुरू कर दिया , जो भंडारण के लिए (बहुत तेज़) Redis सर्वर का उपयोग करने से अलग है (मैं विंडोज़ पोर्ट का उपयोग कर रहा हूं - हालांकि इसमें MSOpenTech पोर्ट भी है ), यह सत्र पर बिल्कुल लॉक नहीं करता है ।

मेरी राय में, यदि आपका एप्लिकेशन उचित तरीके से संरचित है, तो यह कोई समस्या नहीं है। यदि आपको वास्तव में सत्र के भाग के रूप में लॉक, सुसंगत डेटा की आवश्यकता है, तो आपको विशेष रूप से अपने आप लॉक / कंसीडर चेक लागू करना चाहिए।

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

Comments

आपका GitHub लिंक 404-मृत प्रतीत हो रहा है। पुस्तकालयों .io/github/angieslist/AL- Redis नया URL लगता है?

— उवे कीम जूल

लगता है कि लेखक दूसरी कड़ी से भी पुस्तकालय को हटाना चाहता था। मुझे एक परित्यक्त पुस्तकालय का उपयोग करने में संकोच होगा, लेकिन यहां एक कांटा है: github.com/PrintFleet/AL-Redis और एक वैकल्पिक पुस्तकालय यहां से जुड़ा हुआ है: stackoverflow.com/a/10979369/12534

— ईसाई डेवन

Answer 4

मैंने इस धागे में पोस्ट किए गए लिंक के आधार पर एक पुस्तकालय तैयार किया। यह MSDN और CodeProject से उदाहरणों का उपयोग करता है। जेम्स को धन्यवाद।

मैंने जोएल मुलर की सलाह पर संशोधन भी किया।

कोड यहाँ है:

https://github.com/dermeister0/LockFreeSessionState

हैशटेबल मॉड्यूल:

Install-Package Heavysoft.LockFreeSessionState.HashTable

स्केलेओट स्टेटसर्वर मॉड्यूल:

Install-Package Heavysoft.LockFreeSessionState.Soss

कस्टम मॉड्यूल:

Install-Package Heavysoft.LockFreeSessionState.Common

यदि आप Memcached या Redis के समर्थन को लागू करना चाहते हैं, तो इस पैकेज को स्थापित करें। इसके बाद LockFreeSessionStateModule क्लास इनहेरिट करें और अमूर्त तरीके लागू करें।

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

रेडिस का उपयोग करते हुए कुछ लॉक-फ्री सत्र प्रदाता:

• https://github.com/angieslist/AL-Redis (इस धागे में gregmac द्वारा सुझाए गए।)
• https://github.com/welegan/RedisSessionProvider (NuGet: RedisSessionProvider)
• https://github.com/efaruk/playground/tree/master/UnlockedStateProvider (NuGet: UnlockedStateProvider.Redis)

Comments

इसे ScaleOut समाधान से पुस्तकालयों की आवश्यकता है, जो मुफ़्त नहीं है?

— हुगंग लांग

हां, मैंने केवल SOSS के लिए कार्यान्वयन बनाया। आप उल्लेखित Redis सत्र प्रदाताओं का उपयोग कर सकते हैं, यह मुफ़्त है।

— डेर_मिस्टर

हो सकता है कि होन्ग लॉन्ग ने इस बात को याद किया कि आपके पास इन-मेमोरी हैशटेबल कार्यान्वयन और स्केलऑट स्टेटसर्वर के बीच कोई विकल्प नहीं है।

— डेविड डी स्लोओवर

आपके योगदान के लिए धन्यवाद :) मैं यह देखने की कोशिश करूंगा कि यह हमारे द्वारा उपयोग किए जाने वाले कुछ मामलों पर कैसे काम करता है।

— अगस्टिन गरज़ॉन

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

— एन.वी.

Answer 5

जब तक आपके आवेदन की विशेष आवश्यकता नहीं है, मुझे लगता है कि आपके पास 2 दृष्टिकोण हैं:

1. सत्र का उपयोग न करें
2. सत्र का उपयोग करें और जोनल उल्लिखित के रूप में ठीक ट्यूनिंग करें।

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

आप कई तरीकों से व्यवहार की तरह एक सत्र बना सकते हैं, लेकिन अगर यह वर्तमान सत्र को लॉक नहीं करता है, तो यह 'सत्र' नहीं होगा।

आपके द्वारा बताई गई विशिष्ट समस्याओं के लिए मुझे लगता है कि आपको HttpContext.Current.Response.IsClientConnected की जांच करनी चाहिए । यह अनावश्यक निष्पादन को रोकने और क्लाइंट पर इंतजार करने के लिए उपयोगी हो सकता है, हालांकि यह इस समस्या को पूरी तरह से हल नहीं कर सकता है, क्योंकि इसका उपयोग केवल पूलिंग तरीके से किया जा सकता है और async नहीं।

Answer 6

यदि आप अपडेटेड Microsoft.Web.RedisSessionStateProvider(शुरू से 3.0.2) का उपयोग कर रहे हैं, तो आप इसे web.configसमवर्ती सत्रों की अनुमति देने के लिए अपने साथ जोड़ सकते हैं ।

<appSettings>
    <add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
</appSettings>

स्रोत

Comments

निश्चित नहीं कि यह 0. +1 पर क्यों था। बहुत उपयोगी।

— पंगम्मा

क्या यह क्लासिक मोड ऐप पूल में काम करता है? github.com/Azure/aspnet-redis-providers/issues/123

— जंग खाए

क्या यह डिफ़ॉल्ट inProc या सत्र राज्य सेवा प्रदाता के साथ काम करता है?

— निक चैन अब्दुल्ला

ध्यान दें कि यदि आप RedisSessionStateprovider उपयोग कर रहे हैं तो पोस्टर संदर्भ, लेकिन यह इन नए AspNetSessionState Async प्रदाताओं (SQL और Cosmos के लिए) के साथ भी काम कर सकता है क्योंकि यह उनके प्रलेखन में भी है: github.com/nnet/AspNetSessionState मेरा अनुमान है कि यह काम करेगा क्लासिकमोड यदि सत्रस्टैटप्रॉइडर पहले से ही क्लासिक मोड में काम करता है, तो संभवत: सत्र राज्य सामान ASP.Net (IIS नहीं) के अंदर होता है। InProc के साथ यह काम नहीं कर सकता है, लेकिन यह एक समस्या से कम होगा क्योंकि यह एक संसाधन विवाद मुद्दे को हल करता है जो कि खरीद परिदृश्यों के साथ एक बड़ा सौदा है।

— मैडमिशन

Answer 7

ASPNET MVC के लिए, हमने निम्नलिखित कार्य किए:

1. डिफ़ॉल्ट रूप से, SessionStateBehavior.ReadOnlyसभी नियंत्रक की कार्रवाई को ओवरराइड करके सेट करेंDefaultControllerFactory
2. नियंत्रक क्रियाओं पर जिन्हें सत्र राज्य में लिखने की आवश्यकता होती है, इसे सेट करने के लिए विशेषता के साथ चिह्नित करें SessionStateBehavior.Required

कस्टम नियंत्रक बनाएँ और ओवरराइड करें GetControllerSessionBehavior।

    protected override SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, Type controllerType)
    {
        var DefaultSessionStateBehaviour = SessionStateBehaviour.ReadOnly;

        if (controllerType == null)
            return DefaultSessionStateBehaviour;

        var isRequireSessionWrite =
            controllerType.GetCustomAttributes<AcquireSessionLock>(inherit: true).FirstOrDefault() != null;

        if (isRequireSessionWrite)
            return SessionStateBehavior.Required;

        var actionName = requestContext.RouteData.Values["action"].ToString();
        MethodInfo actionMethodInfo;

        try
        {
            actionMethodInfo = controllerType.GetMethod(actionName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance);
        }
        catch (AmbiguousMatchException)
        {
            var httpRequestTypeAttr = GetHttpRequestTypeAttr(requestContext.HttpContext.Request.HttpMethod);

            actionMethodInfo =
                controllerType.GetMethods().FirstOrDefault(
                    mi => mi.Name.Equals(actionName, StringComparison.CurrentCultureIgnoreCase) && mi.GetCustomAttributes(httpRequestTypeAttr, false).Length > 0);
        }

        if (actionMethodInfo == null)
            return DefaultSessionStateBehaviour;

        isRequireSessionWrite = actionMethodInfo.GetCustomAttributes<AcquireSessionLock>(inherit: false).FirstOrDefault() != null;

         return isRequireSessionWrite ? SessionStateBehavior.Required : DefaultSessionStateBehaviour;
    }

    private static Type GetHttpRequestTypeAttr(string httpMethod) 
    {
        switch (httpMethod)
        {
            case "GET":
                return typeof(HttpGetAttribute);
            case "POST":
                return typeof(HttpPostAttribute);
            case "PUT":
                return typeof(HttpPutAttribute);
            case "DELETE":
                return typeof(HttpDeleteAttribute);
            case "HEAD":
                return typeof(HttpHeadAttribute);
            case "PATCH":
                return typeof(HttpPatchAttribute);
            case "OPTIONS":
                return typeof(HttpOptionsAttribute);
        }

        throw new NotSupportedException("unable to determine http method");
    }

AcquireSessionLockAttribute

[AttributeUsage(AttributeTargets.Method)]
public sealed class AcquireSessionLock : Attribute
{ }

में बनाए गए नियंत्रक कारखाने को हुक करें global.asax.cs

ControllerBuilder.Current.SetControllerFactory(typeof(DefaultReadOnlySessionStateControllerFactory));

अब, हम एक एकल में सत्र read-onlyऔर read-writeराज्य दोनों कर सकते हैं Controller।

public class TestController : Controller 
{
    [AcquireSessionLock]
    public ActionResult WriteSession()
    {
        var timeNow = DateTimeOffset.UtcNow.ToString();
        Session["key"] = timeNow;
        return Json(timeNow, JsonRequestBehavior.AllowGet);
    }

    public ActionResult ReadSession()
    {
        var timeNow = Session["key"];
        return Json(timeNow ?? "empty", JsonRequestBehavior.AllowGet);
    }
}

नोट: ASPNET सत्र राज्य को अभी भी आसानी से पढ़ा जा सकता है और अपवाद के किसी भी रूप में नहीं फेंका जाएगा (यह केवल निरंतरता की गारंटी नहीं देता है) इसलिए हमें AcquireSessionLockनियंत्रक कार्यों में चिह्नित करने के लिए सावधान रहना होगा, जिसमें सत्र राज्य की आवश्यकता होती है।

Comments

world.episerver.com/blogs/mahdi-shahbazi/dates/2018/10/…

— Kiquenet

Answer 8

एक नियंत्रक सत्र राज्य के रूप में चिह्नित करना केवल पढ़ने के लिए या विकलांग समस्या का समाधान होगा।

आप केवल पढ़ने के लिए इसे चिह्नित करने के लिए निम्नलिखित विशेषता वाले नियंत्रक को सजा सकते हैं:

[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]

System.Web.SessionState.SessionStateBehavior enum निम्न मान है:

• चूक
• विकलांग
• सिफ़ पढ़िये
• अपेक्षित

Answer 9

बस इस समस्या से किसी की मदद करने के लिए (उसी सत्र से किसी अन्य को निष्पादित करते समय अनुरोधों को लॉक करना) ...

आज मैंने इस मुद्दे को हल करना शुरू कर दिया और, कुछ घंटों के शोध के बाद, मैंने Global.axSession_Start से विधि (भले ही खाली हो) को हटाकर इसे हल किया। फ़ाइल ।

यह मेरे द्वारा परीक्षण की गई सभी परियोजनाओं में काम करता है।

Comments

IDK यह किस प्रकार की परियोजना पर था, लेकिन मेरे पास एक Session_Startविधि नहीं है और अभी भी ताले हैं

— डेनिस जी। लैब्रेक

Answer 10

सभी उपलब्ध विकल्पों के साथ संघर्ष करने के बाद, मैंने एक JWT टोकन आधारित सत्रस्टोर प्रदाता (सत्र कुकी के अंदर यात्रा करता है, और बैकएंड स्टोरेज की आवश्यकता नहीं है) लिखना समाप्त कर दिया।

http://www.drupalonwindows.com/en/content/token-sessionstate

लाभ:

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