क्या मुझे c3p0 स्टेटमेंट पूलिंग सक्रिय करना चाहिए?

Question

हम java6/hibernate/c3p0/postgresql ढेर चला रहे हैं। हमारा जेडीबीसी चालक 8.4-701.jdbc3

मेरे पास तैयार वक्तव्य के बारे में कुछ प्रश्न हैं। मैंने Prepared Statements

पर उत्कृष्ट दस्तावेज़ पढ़ा है लेकिन मुझे अभी भी एक प्रश्न है कि cgpqll के साथ c3p0 को कॉन्फ़िगर कैसे करें।

समय हम

c3p0.maxStatements = 0 
c3p0.maxStatementsPerConnection = 0 

है मेरी समझ में तैयार बयान और बयान पूलिंग दो अलग बातें हैं:

हमारे हाइबरनेट ढेर तैयार बयानों उपयोग करता है। Postgresql निष्पादन योजना कैशिंग कर रहा है। अगली बार एक ही कथन का उपयोग किया जाता है, postgresql निष्पादन योजना का पुन: उपयोग करता है। यह डीबी के अंदर समय नियोजन बयान बचाता है।

इसके अतिरिक्त c3p0 "java.sql.PreparedStatement" के जावा उदाहरणों को कैश कर सकता है जिसका अर्थ है कि यह जावा ऑब्जेक्ट को कैशिंग कर रहा है। तो
c3p0.maxStatementsPerConnection = 100 का उपयोग करते समय यह 100 से अधिक विभिन्न
ऑब्जेक्ट्स पर कैश करता है। यह वस्तुओं को बनाने पर समय बचाता है, लेकिन इसके पास पोस्टग्रेस्क्ल डेटाबेस और इसके तैयार बयान के साथ कुछ लेना देना नहीं है।

सही?

हम के बारे में 100 विभिन्न बयानों का उपयोग के रूप में मैं c3p0.maxStatementsPerConnection = 100

लेकिन c3p0 डॉक्स कहना c3p0 known shortcomings

में वक्तव्य पूलिंग की भूमि के ऊपर बहुत अधिक है स्थापित करेगा। उन ड्राइवरों के लिए जो तैयार प्रीटेक्शंस का महत्वपूर्ण प्रीप्रोकैसिंग करते हैं, पूलिंग ओवरहेड किसी भी बचत से अधिक है। इस प्रकार स्टेटमेंट पूलिंग को डिफ़ॉल्ट रूप से बंद कर दिया गया है। यदि आपका चालक प्रीप्रोसेस प्रीपेडस्टेटमेंट्स, विशेष रूप से यदि यह आरडीबीएमएस के साथ आईपीसी के माध्यम से ऐसा करता है, तो आपको शायद द्वारा महत्वपूर्ण प्रदर्शन लाभ पर स्टेटमेंट पूलिंग चालू कर देगा। (यह कॉन्फ़िगरेशन प्रॉपर्टी अधिकतम स्टेटमेंट्स या maxStatementsPerConnection को मान शून्य से अधिक मानकर सेट करें।)।

तो: क्या c3p0 और Postgresql के साथ maxStatementsPerConnection को सक्रिय करना उचित है? क्या इसका वास्तविक लाभ सक्रिय है?

तरह का संबंध Janning

Answer 1

मैं बेतकल्लुफ़ याद नहीं है हाइबरनेट वास्तव में PreparedStatement उदाहरणों ही संग्रहीत करता है, या कनेक्शन प्रदाता पर निर्भर करता है उन्हें पुन: उपयोग करने के लिए।(बैचरआईएमपीएल का एक त्वरित स्कैन सुझाव देता है कि यदि पंक्ति में एक ही एसक्यूएल कई बार निष्पादित किया जाता है तो यह अंतिम तैयार किए गए स्टेटमेंट का पुन: उपयोग करता है)

मुझे लगता है कि c3p0 दस्तावेज़ बनाने का प्रयास कर रहा है यह है कि कई जेडीबीसी ड्राइवरों के लिए, एक प्रीपेर्डस्टेटेशन isn ' टी उपयोगी: कुछ ड्राइवर क्लाइंट-साइड में पैरामीटर को बस विभाजित कर देंगे और फिर डेटाबेस में बनाए गए SQL कथन को किसी भी तरह से पास कर देंगे। इन ड्राइवरों के लिए, तैयार किए गए स्तरों का कोई फायदा नहीं होता है, और उनका पुन: उपयोग करने का कोई भी प्रयास बर्बाद हो जाता है। (Postgresql JDBC FAQ का कहना है कि यह पोस्टग्रेस्क्ल से अलग प्रोटोकॉल संस्करण 3 से पहले था और documentation में अधिक विस्तृत जानकारी है)।

ड्राइवरों के लिए जो उपयोगी रूप से तैयार किए गए हैंडल को संभालने के लिए, वास्तव में किसी भी लाभ के लिए तैयार किए गए स्टेटमेंट उदाहरणों का पुन: उपयोग करने की आवश्यकता है। उदाहरण के लिए यदि ड्राइवर लागू करता है:

• Connection.prepareStatement (एसक्यूएल) -
• PreparedStatement.close कि सर्वर साइड बयान पर अमल - सर्वर की ओर से बयान
• PreparedStatement.execute (..) आदि बनाने() - सर्वर साइड बयान

यह देखते हुए पुनःआवंटन, अगर आवेदन हमेशा एक तैयार बयान को खोलता है, यह एक बार निष्पादित करता है और फिर इसे फिर से बंद कर देता है, वहाँ अभी भी कोई लाभ नहीं; वास्तव में, यह अब भी बदतर हो सकता है क्योंकि अब संभावित रूप से अधिक गोल-यात्राएं हैं। इसलिए आवेदन को प्रीपेयरस्टेटमेंट उदाहरणों पर लटकने की जरूरत है। बेशक, यह एक और समस्या का कारण बनता है: यदि एप्लिकेशन बहुत अधिक पर लटकता है, और प्रत्येक सर्वर-साइड स्टेटमेंट कुछ संसाधनों का उपभोग करता है, तो इससे सर्वर-साइड समस्याएं हो सकती हैं। ऐसे मामले में जहां कोई सीधे जेडीबीसी का उपयोग कर रहा है, यह हाथ से प्रबंधित किया जा सकता है- कुछ बयानों को पुन: प्रयोज्य माना जाता है और इसलिए तैयार किए जाते हैं; कुछ इसके बजाय क्षणिक वक्तव्य उदाहरणों का उपयोग नहीं करते हैं। (यह तैयार बयानों के अन्य लाभों पर छोड़ रहा है: तर्क से बचने का तर्क)

इसलिए यही कारण है कि सी 3 पी 0 और अन्य कनेक्शन पूलों ने कथन कैश तैयार किए हैं- यह एप्लिकेशन कोड को इन सभी से निपटने से बचने की अनुमति देता है। बयान आमतौर पर कुछ सीमित एलआरयू पूल में रखा जाता है, इसलिए आम कथन एक प्रीपेडस्टेटमेंट इंस्टेंस का पुन: उपयोग करते हैं।

पहेली के अंतिम टुकड़े यह हैं कि जेडीबीसी ड्राइवर स्वयं चालाक होने का फैसला कर सकते हैं और ऐसा कर सकते हैं; और सर्वर स्वयं भी चालाक होने का निर्णय ले सकते हैं और क्लाइंट को एक बयान सबमिट कर सकते हैं जो संरचनात्मक रूप से पिछले के समान है।

यह देखते हुए कि हाइबरनेट स्वयं तैयार किए गए उदाहरणों का कैश नहीं रखता है, तो आपको लाभ प्राप्त करने के लिए सी 3 पी 0 करना होगा। (कैश योजनाओं का पुन: उपयोग करने के कारण सामान्य बयानों के लिए ओवरहेड को कम किया जाना चाहिए)। यदि c3p0 तैयार कथन कैश नहीं करता है, तो ड्राइवर केवल एक कथन तैयार करने, इसे निष्पादित करने, और फिर इसे बंद करने के लिए एप्लिकेशन को देखेगा। ऐसा लगता है कि जेडीबीसी ड्राइवर के पास "threshold" setting है, जहां एप्लिकेशन हमेशा ऐसा करता है, जहां तैयार/निष्पादित सर्वर ओवरहेड से बचने के लिए। तो, हाँ, आपको c3p0 ड्यूटी स्टेटमेंट कैशिंग होना चाहिए।

आशा है कि मदद करता है, खेद है कि यह थोड़ा लंबा हवादार है। जवाब हाँ है।

Answer 2

याद रखें कि बयान कनेक्शन पर कैश किया जाना चाहिए जिसका अर्थ यह होगा कि आपको स्मृति का काफी हिस्सा उपभोग करना होगा और इससे पहले कि आप कोई लाभ देखेंगे, इसमें काफी समय लगेगा। तो यदि आप इसे कैश किए जाने के लिए 100 कथन का उपयोग करने के लिए सेट करते हैं, तो वास्तव में यह 100 * कनेक्शन की संख्या है या अन्य 100/कनेक्शन कनेक्शन नहीं है, लेकिन आपको तब तक कुछ समय लेना होगा जब तक कि आपके कैश का कोई सार्थक प्रभाव न हो।