मैं इस पर रिका से असहमत हूं। Async DB कमांड न केवल अच्छे हैं, वे स्केल, थ्रूपुट प्राप्त करने में महत्वपूर्ण हैं और विलंबता थ्रेड पूल के रैंप अप टाइम के बारे में उनकी आपत्ति केवल उस वेब सर्वर पर लागू होती है जो कम ट्रैफ़िक वॉल्यूम का अनुभव करता है।
एक उच्च यातायात स्थिति में (जो केवल एक ही मायने रखता है), थ्रेड पूल को नए धागे 'इंजेक्शन' के लिए इंतजार नहीं करना पड़ेगा। SQL कमांड को एसिंक्रोनस रूप से करना न केवल वेब सर्वर अनुरोधों/थ्रेड्स स्वास्थ्य के दृष्टिकोण से महत्वपूर्ण है, बल्कि कुल अनुरोध जीवनकाल/विलंबता के दृष्टिकोण से भी महत्वपूर्ण है:अनुक्रमिक रूप से विपरीत, असंबद्ध डीबी कॉल समानांतर में किया जा सकता है। यह अकेला परिणाम आमतौर पर उपयोगकर्ता द्वारा अनुभव किए गए HTTP अनुरोध की विलंबता में नाटकीय सुधार करता है। दूसरे शब्दों में, आपके पृष्ठ तेजी से लोड होते हैं।
सलाह का एक शब्द हालांकि:SQL कमांड वास्तव में अतुल्यकालिक नहीं है जब तक आप अतुल्यकालिक संसाधन=सत्य
कनेक्शन स्ट्रिंग पर। हालांकि यह सेट नहीं है (और डिफ़ॉल्ट रूप से नहीं है, संपादित करें:.NET Framework <4.5 से शुरू करें। एसिंक्रोनस प्रोसेसिंग अब आवश्यक नहीं है
) आपका 'एसिंक्रोनस' BeginExecuteReader
एक दिखावा के अलावा और कुछ नहीं है, कॉल एक थ्रेड लॉन्च करेगी और कि . को ब्लॉक कर देगी धागा। जब सही एसिंक प्रोसेसिंग सक्षम हो कनेक्शन स्ट्रिंग में तो कॉल वास्तव में एसिंक है और कॉलबैक आईओ पूर्ण होने पर आधारित है।
सावधानी का एक शब्द:जैसे ही पहले . एक async SQL कमांड पूरा हो रहा है परिणाम क्लाइंट को लौटाता है, और सूचना संदेश परिणाम के रूप में गिने जाते हैं।
create procedure usp_DetailsTagsGetAllFromApprovedPropsWithCount
as
begin
print 'Hello';
select complex query;
end
आपने async के सभी लाभ खो दिए हैं। प्रिंट एक परिणाम बनाता है जो क्लाइंट को वापस भेजा जाता है, जो एसिंक कमांड को पूरा करता है और क्लाइंट पर निष्पादन फिर से शुरू होता है और 'रीडर.रीड ()' के साथ जारी रहता है। अब वह तब तक ब्लॉक रहेगा जब तक कि जटिल क्वेरी परिणाम देना शुरू न कर दे। आप पूछते हैं 'कौन प्रिंट करता है प्रक्रिया में?' लेकिन प्रिंट हो सकता है किसी और चीज़ के वेश में हो, शायद कुछ ऐसा जो निर्दोष दिख रहा हो INSERT जो बिना निष्पादित करता है पहले एक सेट NOCOUNT ON जारी करना
।
