क्या है नेट अतुल्यकालिक प्रसंस्करण से अधिक एसक्यूएल सर्वर में अतुल्यकालिक प्रसंस्करण उपयोग करने का लाभ है? क्या वे वही नहीं हैं? मुझे समझने में कठिनाई है कि .NET एपीएम के बजाय SQL सर्वर में असीमित प्रक्रिया का उपयोग करने का क्या फायदा है। मैं आसानी से एक लैम्ब्डा अभिव्यक्ति में एक एसक्यूएल कॉल लपेट सकता हूं और एक BeginInvoke (...) कर सकता हूं।अतुल्यकालिक प्रसंस्करण
कोई मुझे फर्क है और दोनों के लाभ में मदद कर सकते हैं?
BeginInvoke(...)) के साथ समस्या यह
कि यह सब है कोड को सिंक्रनाइज़ तरीके से संसाधित करने के लिए थ्रेड को कताई करना है। एक 5 मिनट क्वेरी 5 मिनट के लिए एक धागा बाँध होगा, अवरुद्ध (अर्थात ~ के लिए समय के 99% कुछ नहीं कर रहे), जबकि एक परिणाम दूरदराज के अंत में गणना की जाती है। तनाव के तहत (एक बार में कई प्रश्न) यह थ्रेडपूल को समाप्त कर देगा, एक अवरुद्ध स्थिति में सभी धागे बांध कर। थ्रेडपूल उत्तरदायी नहीं होगा और नए कार्य अनुरोधों को थ्रेडपूल के अतिरिक्त थ्रेडों को आग लगाने के लिए बड़ी विलंबता का सामना करना पड़ेगा। यह थ्रेडपूल का इच्छित उपयोग नहीं है, क्योंकि यह उम्मीद के साथ डिज़ाइन किया गया है कि इसे पूरा करने के लिए कहा जाने वाला कार्य अल्पकालिक और गैर-अवरुद्ध होना है।
आरंभ/समाप्ति एपीएम जोड़े के साथ, कोई भी एक ही कार्रवाई को गैर-अवरुद्ध तरीके से बुला सकता है, और यह तब होता है जब परिणाम आईओ पूर्णता बंदरगाह के माध्यम से वापस किया जाता है जिसे इसे थ्रेडपूल में कार्य आइटम के रूप में कतारबद्ध किया जाता है। अपने सूत्र में से कोई भी अंतरिम में करार कर रहे हैं, और मुद्दा यह है कि पंक्तिबद्ध प्रतिक्रिया के साथ पेश किया गया है पर, डेटा उपयोगकर्ता कोड अर्थ आईओ पर ब्लॉक नहीं करता उपलब्ध है, और जल्दी से पूरा किया जा सकता ... की एक और अधिक कुशल उपयोग थ्रेडपूल जो बकाया ऑपरेशन के थ्रेड की लागत के बिना कई और क्लाइंट अनुरोधों के लिए स्केल करता है।
इस लेख SQL Server 2008 Books Online (October 2009) - Performing Asynchronous Operations से, मैं बोली:
अतुल्यकालिक प्रसंस्करण तरीकों बुला धागे पर ब्लॉक किए बिना तुरंत वापस जाने के लिए सक्षम बनाता है। यह अधिक बिजली और मल्टीथ्रेडिंग की लचीलापन देता है, के बिना डेवलपर को स्पष्ट रूप से धागे बनाने या सिंक्रनाइज़ेशन को संभालने की आवश्यकता होती है।
यदि आपने स्पष्ट रूप से उन धागे बनाए हैं और सिंक्रनाइज़ेशन को संभाला है, तो शायद आपको शायद अधिक अंतर नहीं मिलेगा।
तो तुम्हारा मतलब "क्यों एक डेटा प्रदाताओं BeginExecute___()/EndExecute____() तरीकों बनाम सिर्फ एक प्रतिनिधि में एक सामान्य Execute____() लपेटकर उपयोग करते हैं, मुझे लगता है इस सवाल का जवाब यह है कि जब वे पहली बार नेट 1.0 के लिए ado.net के लिए प्रदाता मॉडल के डिजाइन किए गए थे, कुछ लपेटकर एक प्रतिनिधि में और इसे अतुल्यकालिक रूप से आमंत्रित करना इतना आसान नहीं था।
अन्य संभावित कारण यह है कि यह मिलान किया गया कि पुराने कोड को वे मूल के लिए अपडेट या रैपिंग कैसे करते थे। नेट काम करता था या अंतर्निहित विधियां आपको आसानी से अनुमति देती हैं जाँच किसी भी लौटे अपवाद
उनके से हो सकता है कि एमएस लोग। नेट टीम बेहतर जानती है: पी –
एसक्लक्लिएंट की शुरुआतएक्सक्यूट/एंडएक्सक्यूट का उपयोग async IO का उपयोग करें यदि कनेक्शन ठीक से कॉन्फ़िगर किया गया है, तो वे केवल एक साधारण प्रतिनिधि एसिंक नहीं हैं। –
नेट BeginInvoke बस एक अलग थ्रेड में निष्पादन स्थगित। यह हमेशा एक तुल्यकालिक कॉल से धीमा होगा और अतिरिक्त संसाधनों का उपभोग करेगा। इसका उपयोग करने का एकमात्र कारण कॉलर संदर्भ को अन्य परिचालनों में आगे बढ़ने के लिए मुक्त करना होगा (उदाहरण के लिए क्लाइंट को HTTP अनुरोध का परिणाम लौटाएं)।
एसक्लक्लिएंट एसिंक्रोनस विधियों, जब AsynchronousProcessing कनेक्शन पर संपत्ति सत्य पर सेट की गई है और SqlCommand के BeginExecute विधियों का उपयोग किया जाता है, वास्तव में असीमित हैं।SQL कमांड को नेटवर्क संचार चैनल पर पोस्ट किया गया है और सर्वर द्वारा परिणाम लौटाए जाने पर पूरा होने का आह्वान किया जाता है।
एक विश्वसनीयता बिंदु से हालांकि हालांकि इनमें से कोई भी विधि उपयोगी नहीं है। वे कॉल क्लाइंट पूरा होने तक चारों ओर रहने के लिए क्लाइंट प्रक्रिया पर भरोसा करते हैं, अन्यथा SQL सर्वर क्लाइंट डिस्कनेक्ट और प्रसंस्करण छोड़ देगा, किसी भी मध्यवर्ती काम को वापस रोलिंग करेगा। एक एएसपी एप्लिकेशन पर विचार करें जो एक HTTP अनुरोध स्वीकार करता है, एक 'एसिंक्रोनस' भुगतान प्रसंस्करण प्रस्तुत करता है और एक प्रतिक्रिया देता है। गारंटी देने का कोई तरीका नहीं है कि सबमिट किया गया कार्य वास्तव में होगा।
ऐसी परिस्थितियों के लिए जब प्रसंस्करण की विश्वसनीयता की गारंटी होती है तो समाधान सर्वर पर काम को कतारबद्ध करता है, इसे प्रतिबद्ध करता है और फिर आगे बढ़ता है, SQL सर्वर की अपनी असीमित प्रक्रिया क्षमताओं पर निर्भर करता है। यह एक तरीका है जो क्लाइंट डिस्कनेक्ट्स, एएसपी प्रोसेस 'रीसाइक्लिंग', एसक्यूएल सर्वर मिररिंग या क्लस्टरिंग फेलओवर, हार्डवेयर आपदा रिकवरी, जो कुछ भी आप इसे फेंक सकते हैं, की प्रस्तुति पर भी प्रोसेसिंग की गारंटी देता है, क्योंकि जमा करने का एक लेनदेन टिकाऊ तरीका है असीमित प्रक्रिया अनुरोध। उदाहरण के लिए Asynchronous Procedure Execution देखें।
जैसा कि पहले के उत्तरों में बताया गया है, BeginInvoke एक .NET थ्रेड का उपयोग करता है। उतना ही महत्वपूर्ण है, हालांकि, यह धागा एएसपी.नेट थ्रेड पूल से आता है, इसलिए यह बहुत सीमित थ्रेड संसाधनों के लिए ग्राहकों के साथ प्रतिस्पर्धा करता है। ThreadPool.QueueUserWorkItem() के लिए भी यही सच है।
SqlClient async कॉल को SqlConnection की आवश्यकता होती है जिसमें async = true सक्षम है। उस मोड को थोड़ा और नेटवर्क ओवरहेड की आवश्यकता होती है (यही कारण है कि यह डिफ़ॉल्ट रूप से सक्षम नहीं है), लेकिन यह .NET थ्रेड पूल से थ्रेड का उपभोग नहीं करता है। इसके बजाय, यह async I/O का उपयोग करता है।
बाद के दृष्टिकोण का लाभ यह है कि यह अधिक स्केलेबल है। आप उस तरह से सैकड़ों या हजारों अनुरोधों को संसाधित कर सकते हैं, जहां थ्रेड-प्रति-कॉल वाला ओवरहेड चरम होगा। इसके अलावा, आप पूरे एएसपी.नेट थ्रेड पूल को बहुत जल्दी उपभोग करेंगे (इसमें डिफ़ॉल्ट रूप से अधिकतम 12 धागे हैं)।
मुझे लगता है कि वह अर्थ है "एक डेटा प्रदाताओं का उपयोग क्यों 'BeginExecute ___()/EndExecute ____()' बस एक प्रतिनिधि –
@Joel में उन्हें लपेटकर बनाम:।। हम्म .. शायद आप ठीक कह रहे हैं –