अगर हाइबरनेट वास्तव में रेडीस्टेडमेंट इंस्टेंस को स्टोर करता है, या उन्हें पुन:उपयोग करने के लिए कनेक्शन प्रदाता पर निर्भर करता है, तो मुझे ऑफहैंड याद नहीं है। (BatcherImpl का एक त्वरित स्कैन यह सुझाव देता है कि यदि एक ही SQL को एक पंक्ति में कई बार निष्पादित किया जाता है तो यह अंतिम तैयार किए गए स्टेटमेंट का पुन:उपयोग करता है)
मुझे लगता है कि c3p0 दस्तावेज बनाने की कोशिश कर रहा है कि कई जेडीबीसी ड्राइवरों के लिए, एक तैयार स्टेटमेंट उपयोगी नहीं है:कुछ ड्राइवर क्लाइंट-साइड में पैरामीटर को आसानी से विभाजित कर देंगे और फिर डेटाबेस में निर्मित SQL कथन को पास कर देंगे। . इन ड्राइवरों के लिए, तैयार बयानों का कोई फायदा नहीं है, और उनका पुन:उपयोग करने का कोई भी प्रयास व्यर्थ है। (पोस्टग्रेस्क्ल जेडीबीसी एफएक्यू का कहना है कि यह पोस्टग्रेस्क्ल के लिए सेवर प्रोटोकॉल संस्करण 3 से पहले का मामला था और दस्तावेज़ीकरण में अधिक विस्तृत जानकारी है)।
उन ड्राइवरों के लिए जो रेडीस्टेटमेंट को उपयोगी रूप से संभालते हैं, किसी भी लाभ को प्राप्त करने के लिए वास्तव में रेडीस्टेडमेंट इंस्टेंस का पुन:उपयोग करना अभी भी आवश्यक है। उदाहरण के लिए यदि ड्राइवर लागू करता है:
- Connection.prepareStatement(sql) - सर्वर-साइड स्टेटमेंट बनाएं
- PreparedStatement.execute(..) आदि - उस सर्वर-साइड स्टेटमेंट को निष्पादित करें
- PreparedStatement.close() - सर्वर-साइड स्टेटमेंट को डीलोकेट करें
इसे देखते हुए, यदि एप्लिकेशन हमेशा एक तैयार कथन खोलता है, इसे एक बार निष्पादित करता है और फिर इसे फिर से बंद कर देता है, तो अभी भी है कोई फायदा नहीं; वास्तव में, यह और भी बुरा हो सकता है क्योंकि अब संभावित रूप से अधिक राउंड-ट्रिप हैं। इसलिए एप्लिकेशन को रेडीस्टेडमेंट इंस्टेंस पर लटकने की जरूरत है। बेशक, यह एक और समस्या की ओर ले जाता है:यदि एप्लिकेशन बहुत अधिक हैंग हो जाता है, और प्रत्येक सर्वर-साइड स्टेटमेंट कुछ संसाधनों का उपभोग करता है, तो इससे सर्वर-साइड समस्याएँ हो सकती हैं। ऐसे मामले में जहां कोई सीधे जेडीबीसी का उपयोग कर रहा है, इसे हाथ से प्रबंधित किया जा सकता है- कुछ बयान पुन:प्रयोज्य होने के लिए जाने जाते हैं और इसलिए तैयार किए जाते हैं; कुछ नहीं हैं और इसके बजाय केवल क्षणिक वक्तव्य उदाहरणों का उपयोग करते हैं। (यह तैयार बयानों के अन्य लाभों को छोड़ रहा है:तर्क से बचना)
तो यही कारण है कि c3p0 और अन्य कनेक्शन पूल ने भी स्टेटमेंट कैश तैयार किए हैं- यह एप्लिकेशन कोड को इन सब से निपटने से बचने की अनुमति देता है। बयानों को आम तौर पर कुछ सीमित एलआरयू पूल में रखा जाता है, इसलिए सामान्य बयान एक तैयार स्टेटमेंट उदाहरण का पुन:उपयोग करते हैं।
पहेली के अंतिम टुकड़े यह हैं कि JDBC ड्राइवर स्वयं चतुर होने का निर्णय ले सकते हैं और ऐसा कर सकते हैं; और सर्वर स्वयं भी चतुर होने का निर्णय ले सकते हैं और एक क्लाइंट को एक स्टेटमेंट सबमिट करने का पता लगा सकते हैं जो संरचनात्मक रूप से पिछले एक के समान है।
यह देखते हुए कि हाइबरनेट स्वयं तैयार किए गए उदाहरणों का कैश नहीं रखता है, आपको उनका लाभ प्राप्त करने के लिए c3p0 ऐसा करने की आवश्यकता है। (जो कैश्ड योजनाओं का पुन:उपयोग करने के कारण सामान्य बयानों के लिए ओवरहेड कम किया जाना चाहिए)। यदि c3p0 तैयार किए गए कथनों को कैश नहीं करता है, तो ड्राइवर केवल एप्लिकेशन को एक स्टेटमेंट तैयार करते हुए, इसे निष्पादित करते हुए, और फिर इसे फिर से बंद करते हुए देखेगा। ऐसा लगता है कि JDBC ड्राइवर के पास उस स्थिति में सर्वर ओवरहेड तैयार/निष्पादित करने से बचने के लिए "थ्रेसहोल्ड" सेटिंग है जहां एप्लिकेशन हमेशा ऐसा करता है। तो, हाँ, आपके पास c3p0 डू स्टेटमेंट कैशिंग होना चाहिए।
आशा है कि यह मदद करता है, क्षमा करें, यह थोड़ा लंबा घुमावदार है। इसका उत्तर है हां ।
