आप आम तौर पर सही रास्ते पर हैं और आपका विश्लेषण सटीक लगता है। कुछ टिप्पणियाँ:
विकल्प 2 (रख-रखाव को चालू करना) Npgsql के पूल में निष्क्रिय कनेक्शनों को हटाने में मदद करेगा जो टूट गए हैं। जैसा कि आपने लिखा है, आपका आवेदन अभी भी कुछ विफल होगा (क्योंकि कुछ खराब निष्क्रिय कनेक्शन समय पर नहीं हटाए जा सकते हैं)। यह सोचने का कोई विशेष कारण नहीं है कि इससे और समस्याएँ पैदा होंगी - इसे चालू करना काफी सुरक्षित होना चाहिए।
विकल्प 3 वास्तव में perf के लिए समस्याग्रस्त है, क्योंकि हर बार डेटाबेस कनेक्शन की आवश्यकता होने पर pgbouncer के लिए एक टीसीपी कनेक्शन स्थापित करना होगा। यह 100% विफल-सबूत तंत्र भी प्रदान नहीं करेगा, क्योंकि कनेक्शन के उपयोग में होने पर भी pgbouncer ड्रॉप आउट हो सकता है।
दिन के अंत में, आप मनमाने ढंग से नेटवर्क/सर्वर विफलता के मामले में लचीलापन के बारे में पूछ रहे हैं, जिसे हासिल करना आसान बात नहीं है। इससे निपटने का एकमात्र 100% विश्वसनीय तरीका आपके आवेदन में है, एक समर्पित परत के माध्यम से जो एक क्षणिक अपवाद होने पर संचालन का पुन:प्रयास करेगा। आप Poly
देखना चाहेंगे , और ध्यान दें कि Npgsql एक IsTransient
अपवाद जिसे पुन:प्रयास करने के लिए ट्रिगर के रूप में उपयोग किया जा सकता है (इकाई फ्रेमवर्क कोर में एक समान "पुन:प्रयास रणनीति" भी शामिल है)। यदि आप इस रास्ते से नीचे जाते हैं, तो ध्यान दें कि लेन-देन को सही ढंग से संभालना विशेष रूप से कठिन है।
