ओडीपी.नेट: कनेक्शन पूलिंग के साथ कनेक्शन टाइमआउट से बचें

Question

एक साइट पर मैं एसक्यूएल डेवलपर के साथ ओरेकल डेटाबेस से कनेक्ट कर सकता हूं, इसे लंबे समय तक निष्क्रिय कर सकता हूं (उदाहरण के लिए,> 60 मिनट), और वापस, और यह ठीक है। दूसरी साइट पर, यदि यह 5-10 मिनट से अधिक समय तक निष्क्रिय रहता है (मैंने बिल्कुल गिनती नहीं की है), तो यह उस स्थिति में SQL डेवलपर को छोड़ देता है जहां नए ऑपरेशन टाइमआउट होंगे और मुझे मैन्युअल रूप से "डिस्कनेक्ट" करने की आवश्यकता है और फिर क्रम में पुनः कनेक्ट करना होगा कुछ भी उपयोगी करने के लिए। यह दूसरी साइट पर एक कनेक्शन टाइमआउट प्रतीत होता है, और मुझे नहीं पता कि इसका क्या कारण है (और मैं जानना चाहता हूं कि इसे कैसे बंद किया जाए, हालांकि यह मेरा मुख्य प्रश्न नहीं है)।

मेरा प्रोग्राम ODP.NET का उपयोग करता है और स्पर्ट्स में आने वाले डेटा को संसाधित करता है। हर 30 मिनट (चर्चा के लिए) इसे संसाधित करने के लिए डेटा का एक गुच्छा मिलेगा जिसमें कई बार दोहराए गए कनेक्शन शामिल होंगे। यह कनेक्शन पूलिंग का भी उपयोग करता है। मैंने 5 मिनट के लाइफटाइम का उपयोग करने के लिए कनेक्शन पूल सेट किया है।

जो मैं दूसरी साइट पर देख रहा हूं (और पहले नहीं) क्या मेरा प्रोग्राम डेटा के प्रत्येक विस्तार की शुरुआत में कनेक्शन टाइमआउट अपवाद (उदा। ओआरए-03113) प्राप्त करेगा। मेरा मानना ​​है कि यह हो रहा है कि डेटा के विस्तार के दौरान, कनेक्शन पूल को डिज़ाइन के रूप में उपयोग किया जाता है। स्पर्ट के अंत में "कनेक्शन लाइफटाइम" चेक किया गया है, और कनेक्शन बहुत पुराना नहीं है, इसलिए यह कनेक्शन पूल में छोड़ा गया है। फिर, 30 मिनट बाद जब नया डेटा आता है, कनेक्शन पूल से बाहर निकाला जाता है (और जीवन भर या टाइमआउट के लिए चेक नहीं किया जाता है) और उपयोग किया जाता है, और जैसे ही मैं SQL डेवलपर में देखता हूं।

मैं कनेक्शन टाइमआउट से कैसे बच सकता हूं लेकिन अभी भी स्पर्ट्स के दौरान कनेक्शन पूल का लाभ उठा सकता हूं? यह प्रलेखन (और मेरा अनुभव) से लगता है कि कनेक्शन केवल पूल में जाने पर लाइफटाइम के लिए चेक किया जाता है, और जब यह बाहर आता है।

Answer 1

आप OracleCommand.ConnectionTimeout संपत्ति 0 पर सेट करके अनंत टाइमआउट निर्दिष्ट कर सकते हैं इस मामले में कोई टाइमआउट नहीं होगा (कम से कम क्लाइंट-साइड पर)।

इस मामले में कनेक्शनपूल का भी उपयोग किया जाता है।

Answer 2

यदि पहली साइट में 5 मिनट लाइफटाइम सेटिंग अच्छी तरह से कर रही है, तो मुझे लगता है कि यह ओरेकल सर्वर पक्ष में प्रोफ़ाइल में निष्क्रिय सत्र टाइमआउट सेट करने वाले किसी व्यक्ति के कारण हो सकता है।

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

Answer 3

यह वास्तव में एक पुराना सवाल है लेकिन मुझे एप्लिकेशन के साथ कुछ समान समस्याएं आ रही हैं और इसलिए मुझे लगता है कि कुछ जानकारी इस प्रश्न पर यात्रा करने वाले किसी और की मदद कर सकती है।

टीएल; डीआर सारांश यह है कि ओडीपी.NET ड्राइवर और .NET कार्यान्वयन एक दूसरे के साथ अच्छी तरह से नहीं खेलता है और इसलिए मिल कनेक्शन पूलिंग सेटिंग्स का आपका सामान्य रन ठीक से काम नहीं करता है कि आप कैसे उम्मीद करेंगे ।

• कनेक्शन लाइफटाइम प्राथमिक अपराधी है। मुझे यकीन नहीं है कि this blog अभी भी लागू है क्योंकि यह काफी पुराना है लेकिन मुझे अभी तक इसका खंडन करने के लिए कोई दस्तावेज नहीं मिला है और ऐसा लगता है कि मैं जो व्यवहार देख रहा हूं उसे सत्यापित करना प्रतीत होता है। ब्लॉग के मुताबिक, कनेक्शन लाइफटाइम अपेक्षित के रूप में पुराने सत्र को मारता है लेकिन इस पैरामीटर के खिलाफ जांच केवल तब होती है जब डेटाबेस पर कॉल किया जाता है। तो दूसरे शब्दों में, लंबे समय तक चलने वाले निष्क्रिय सत्र कभी भी .NET द्वारा नहीं मारे जाएंगे।
• यदि आपके पास IDLE_TIME आपके ओरेकल उपयोगकर्ता प्रोफ़ाइल (और UNLIMITED) में किसी मान पर सेट नहीं है तो आखिरकार इन लंबे चलने वाले निष्क्रिय पैरामीटर डेटाबेस द्वारा SNIPED होंगे। यह .NET पक्ष पर समस्याएं उत्पन्न कर सकता है क्योंकि जब तक कि आप स्पष्ट रूप से जांच नहीं कर रहे हैं कि आपके कनेक्शन अभी भी खुले हैं, .NET इन SNIPED कनेक्शनों को सेवा प्रदान करने जा रहा है जैसे कि वे अभी भी उपलब्ध हैं (इस प्रकार उपरोक्त टाइमआउट ओआरए त्रुटि को फेंक रहे हैं)।
• इस समस्या के आसपास की चाल यह सुनिश्चित करने के लिए है कि आपके कनेक्शन स्ट्रिंग में Data Validation=True; है। यह सुनिश्चित करता है कि .NET अगले सेवा कॉल तक कनेक्शन की सेवा करने से पहले सत्र कनेक्टिविटी की जांच करेगा। जब यह सत्यापन SNIPED सत्र देखता है तो यह इसे .NET कनेक्शन पूल से हटा देता है।

इस जानकारी को देखते हुए, यह संभवतः ओपी की मूल समस्या केवल एक साइट में अलग-अलग डेटाबेस सेटिंग्स और/या डेटाबेस में .NET कॉल की आवृत्ति के संयोजन से दिखाई दे रही थी। उन्हें दोनों वातावरण में समस्या हो सकती है, लेकिन यदि एक वातावरण में उपयोगकर्ता Connection Lifetime के लिए अक्सर नौकरी करने के लिए कॉल कर रहे थे तो वह उस डेटाबेस में इन टाइमआउट को कभी नहीं देख पाएगा।

अब भी मुझे पता नहीं चला है कि किसी भी ओरेकल IDLE_TIME स्निपिंग होने से पहले .NET में निष्क्रिय कनेक्शन को कैसे मारना है, लेकिन जब तक आप Data Validation = True पैरामीटर का उपयोग करते हैं, तो आपको उम्मीद है कि इस समस्या के आसपास काम करने में सक्षम होना चाहिए।