जावा

Question

में 2-चरण प्रतिबद्धता का परीक्षण करने के लिए डेटाबेस विफलता का अनुकरण कैसे करें मैं वितरित संसाधनों सहित 2-चरण प्रतिबद्धता को कार्यान्वित कर रहा हूं। मैं भाग लेने वाले डेटाबेस की विफलता का अनुकरण कैसे करूं? नेटवर्क केबल को खींचना काम नहीं करता क्योंकि यह टेबल डेडलॉक का कारण बनता है। मैं वर्तमान में अपने आवेदन कोड में हुक का उपयोग कर रहा हूं जो पूछताछ के बाद क्वेरी निष्पादन से पहले विभिन्न बिंदुओं पर StaleConnectionException फेंक देता है। इस दृष्टिकोण के साथ मेरी चिंता है:

• क्या डीबी विफलता अनुकरण करने का कोई बेहतर तरीका है?
• डीबी कनेक्शन खराब होने पर कनेक्शन ऑब्जेक्ट का क्या होता है? क्या यह अपना मूल्य बरकरार रखता है या क्या यह शून्य हो जाता है?
• वास्तव में क्या होता है जब एप्लिकेशन डीबी से पुनः कनेक्ट करने का प्रयास करता है? कनेक्शन ऑब्जेक्ट का क्या मूल्य मिलता है? क्या यह कनेक्शन पूल से मौजूदा मान का उपयोग करता है?

मैं भी मध्यवर्ती अंक पर परीक्षण करने के लिए की तरह क्वेरी निष्पादन के दौरान, के दौरान प्रतिबद्ध चाहते हैं (के बाद, तैयार भेज दिया जाता है आदि)। अभी मैं एप्लिकेशन को डीबग मोड में डालता हूं और फ़ंक्शन कॉल में कदम डालता हूं और प्लग को बीच में खींचता हूं। लेकिन यह दृष्टिकोण मैनुअल है और स्केल परीक्षण के लिए काम नहीं करेगा।

क्या कोई सिम्युलेटर/एमुलेटर या उपकरण है जो मुझे ऐसा करने में मदद कर सकता है?

Answer 1

शायद आप अपना संसाधन जोड़ सकते हैं जो प्रतिबद्धता में भाग लेगा और पहले चरण के बाद लेनदेन को रोक देगा। इस बीच आप "प्लग खींच सकते हैं"।

Answer 2

Andrej ने प्रश्न के एक हिस्से का उत्तर दिया, तो मुझे दूसरे भाग का जवाब दें।

आपके आवेदन में प्राप्त कनेक्शन ऑब्जेक्ट केवल भौतिक कनेक्शन के आसपास एक रैपर है। वह रैपर कनेक्शन पूलिंग और लेनदेन प्रबंधन में एक भूमिका निभाता है। यदि डीबी के साथ कुछ भी गलत हो जाता है, तो कनेक्शन रैपर अनुपयोगी हो जाता है और आप केवल रोलबैक कर सकते हैं। यह समझ में आता है क्योंकि आप 2 पीसी शुरू होने से पहले कनेक्शन तक पहुंचते हैं, और 2 पीसी की शुरुआत से पहले किए गए कुछ भी नहीं किए जा सकते हैं।

ध्यान दें कि कनेक्शन जारी करने और एक नया अधिग्रहण करने का प्रयास कुछ भी नहीं बदलेगा क्योंकि लेनदेन में किसी दिए गए डेटा स्रोत से कनेक्शन का उपयोग करने के बाद, आप हमेशा उस डेटा स्रोत से उसी कनेक्शन को प्राप्त करेंगे जैसा कि आप एक ही लेनदेन में हैं। इसका मतलब है कि आपका एप्लिकेशन पूरे लेन-देन को पुनरारंभ किए बिना "पुनः कनेक्ट" नहीं कर सकता है।

दूसरी तरफ, यदि सभी संसाधन तैयार किए जाने के बाद कुछ गलत हो जाता है लेकिन सभी संसाधनों के पहले, लेनदेन को पुनर्प्राप्त करने के लिए लेनदेन प्रबंधक की ज़िम्मेदारी है। लेकिन यह दृश्य के पीछे होता है और आपके आवेदन पर कोई नियंत्रण नहीं होता है। इस बिंदु पर, आपके आवेदन से उस लेनदेन में उपयोग किए गए सभी कनेक्शन जारी किए जाने की उम्मीद है।

Answer 3

आपकी सर्वश्रेष्ठ शर्त शायद स्मृति डेटाबेस में उपयोग करने के लिए है। विफलता को शामिल करें और रोलबैक/प्रतिबद्धता को सही तरीके से निष्पादित करने के लिए पहले और बाद में डेटा स्रोतों की स्थिति की जांच करें।

आपकी अन्य चिंताओं के लिए ये बेहद उच्च लागत/कम इनाम परीक्षण की तरह लगते हैं। अपने विक्रेताओं के दस्तावेज पढ़ें और सुनिश्चित करें कि आपका लेनदेन वातावरण उचित रूप से कॉन्फ़िगर किया गया है। ऐसा करने के लिए आपको शायद इसे स्वचालित करना चाहिए ताकि उसके हाथ बंद हो जाएं।

जब तक आप अपना 2 पीसी प्रोटोकॉल विशिष्ट लेनदेन प्रबंधक + डीबी कार्यान्वयन नहीं लिखते हैं, तो मैं आपके विक्रेता की उन सुविधाओं का परीक्षण छोड़ दूंगा।

Answer 4

यह बहुत सारे प्रश्न हैं :) मैं पिछले उत्तरों को पूरा करने की कोशिश करूंगा।

Is there a better way to simulate the DB failure? 

परीक्षण सभी मामलों जटिल है। मुख्य मामलों का परीक्षण करने का एक तरीका एक जेसीए कनेक्टर बनाना होगा (एक डीबी चालक एक जेसीए कनेक्टर है)। आप कनेक्टर से कनेक्शन प्राप्त कर सकते हैं जिसे लेनदेन में सूचीबद्ध किया जाएगा (एक तीसरा प्रतिभागी)। कनेक्शन तब कुछ त्रुटियों को बढ़ा सकता है।

तीन भाग हैं जो एक साथ काम करते हैं: (1) आवेदन, (2) ऐप। सर्वर का लेनदेन प्रबंधक, और (3) जेसीए कनेक्टर (तथाकथित संसाधन एडाप्टर)।

ManagedConnection.getXAResource के माध्यम से लेन-देन में कनेक्शन हुक ही। कस्टम जेसीए कनेक्टर के साथ आप एप्लिकेशन में अपवाद बढ़ा सकते हैं (चित्र में Connection) या एप्लिकेशन सर्वर के लेनदेन प्रबंधक (XAResource चित्र में ManagedConnection के माध्यम से प्राप्त)। आप XAResource.prepare और XAResource.commit के दौरान विशेष रूप से अपवाद फेंक सकते हैं, जो त्रुटियों के अनुरूप 2 चरण प्रतिबद्धता के दौरान होता है।

ध्यान दें कि प्रतिभागियों के उत्थान के आदेश को नियंत्रित करना मुश्किल है (this question देखें)। तो यह जांचना आसान है कि prepare में से एक विफल रहता है (अर्थात् आपका), लेकिन उस क्रम को नियंत्रित करना मुश्किल है जिसमें उन्हें बुलाया जाता है। 2 चरण प्रतिबद्धता के सभी संभावित अमान्य राज्यों को पुन: उत्पादित करना जटिल है, खासकर जब खेल में अनुकूलन लेना।

(मैं एक बार एक JCA कनेक्टर (http://code.google.com/p/txfs) ने लिखा है और यदि आप नमूना कोड चाहते हैं वहाँ दूसरों आसपास हैं,।)

What happens to the connection object when DB connection goes bad? 
Does it retain its value or does it become null? 

ManagedConnection लेन-देन के प्रबंधक को सूचित कर सकते हैं। अधिसूचना में से एक ConnectionEvent.CONNECTION_ERROR_OCCURRED है जो यह सूचित करता है कि इस विशेष कनेक्शन का उपयोग करते समय एक त्रुटि हुई।

जैसा कि अन्य उत्तर में बताया गया है, आमतौर पर प्रति लेनदेन से जुड़े एक प्रबंधित कनेक्शन होते हैं। प्रबंधित कनेक्शन भौतिक कनेक्शन को सारणीबद्ध करता है, और आप बहुत अधिक उपयोग नहीं करना चाहते हैं। एप्लिकेशन को केवल "हैंडल" प्राप्त होता है (चित्र में Connection)। एक ही लेनदेन के भीतर हैंडल एक ही प्रबंधित कनेक्शन के लिए सभी बिंदुओं को प्राप्त करते हैं। यह एक अनुकूलन है कि अधिकांश ऐप सर्वर समर्थन करते हैं।

यदि प्रबंधित कनेक्शन अमान्य हो जाता है, तो इसका उपयोग करने वाले हैंडल भी अमान्य हो जाते हैं। लेकिन हैंडल AFAIK को "ताज़ा" नहीं कर सकते हैं। लेनदेन रोलबैक होना चाहिए, प्रबंधित कनेक्शन नष्ट हो गया है। जब कोई अन्य लेनदेन शुरू होता है तो यह पूल से दूसरे वैध प्रबंधित कनेक्शन से जुड़ा होगा।

What actually happens when application tries to reconnect to DB? 
What value does connection object get? 
Does it use an existing value from the connection pool? 

अनुप्रयोग सर्वर में कामयाब कनेक्शन का एक पूल प्रबंधन करता है। जैसा कि पिछले अनुच्छेद में कहा गया है, इसका इस्तेमाल होने पर बुरा हो सकता है। लेकिन इस्तेमाल किए बिना भी बुरा हो सकता है। उदाहरण के लिए, पूल में एक प्रबंधित प्रबंधित कनेक्शन अमान्य हो सकता है क्योंकि अंतर्निहित भौतिक कनेक्शन का समय समाप्त हो गया है। ऐप सर्वर आमतौर पर यह जांचने के लिए एक सुविधा होती है कि प्रबंधित कनेक्शन वैध है या नहीं, इससे पहले कि इसका उपयोग शुरू हो जाए।यदि नहीं, तो यह पूल से एक और प्रबंधित कनेक्शन आज़माएगा, या एक नया बना देगा।