व्यावसायिक अनुप्रयोगों के लिए समानांतर प्रोग्रामिंग पैटर्न की विशेषताएं [PoEAA]

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

एक साथ उपयोग के विभिन्न स्तरों पर ऑफलाइन लॉक पैटर्न का कार्यान्वयन व्यवहार [आशावादी ऑफ़लाइन लॉक, निराशावादी ऑफ़लाइन लॉक]

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

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

CREATE TABLE values ( "id" integer PRIMARY KEY, "field1" varchar(4096), "field2" decimal(20, 2), "locked" boolean, "version" integer DEFAULT 0 ); INSERT INTO values ( "id", "field1", "field2", "locked", "version" ) VALUES ( 1,'record 1', 0.00, false, 0 ); 

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

 @Entity @Table(name="values", schema="public") public class Value { @Id private Integer id; private String field1; private BigDecimal field2; private Boolean locked; private Integer version; //   } 

ऑफ़लाइन लॉक पैटर्न में से प्रत्येक के कार्यान्वयन में दो कक्षाएं DAO और टास्क शामिल हैं। DAO डेटाबेस तक पहुँचने और तालों की जाँच के लिए सभी तर्क को लागू करता है। टास्क में, डेटा को बदलने के लिए एक कोड एक साथ एक्सेस कंट्रोल के लिए नियंत्रण का प्रकार और परीक्षण के लिए एक विशिष्ट कोड होता है। नोट 1: दो पैटर्न (पेसिमिसिटिक और ऑप्टिमिस्टिक) के कार्यान्वयन के बीच समानता को अधिकतम करने के लिए लॉक मैनेजर पैटर्न का उपयोग किए बिना निराशावादी ऑफ़लाइन लॉक लागू किया जाता है। नोट 2: ऑप्टिमिस्टिक ऑफ़लाइन लॉक पैटर्न को लागू करते समय, मैन्युअल संस्करण नियंत्रण का उपयोग फिर से किया गया था, समानता के कारणों के लिए, एक वास्तविक एप्लिकेशन में अंतर्निहित हाइबरनेट तंत्र का उपयोग करना बेहतर होता है।

आशावादी ऑफ़लाइन लॉक कार्यान्वयन कोड

 @Repository("optimisticDao") @Scope("prototype") public class ValueDaoWithOptimisticControl implements ValueDao { //    @Transactional @Override public Value loadValue(Integer id) { //    Value value = (Value) sessionFactory.getCurrentSession().get( Value.class, id ); return value; } @Transactional @Override public void storeValue(Value value) { //          Value oldValue = (Value) sessionFactory.getCurrentSession().get( Value.class, value.getId(), new LockOptions(LockMode.PESSIMISTIC_WRITE) ); if (!value.getVersion().equals(oldValue.getVersion())) throw new OptimisticLockingFailureException("Value was modified"); oldValue.setField1(value.getField1()); oldValue.setField2(value.getField2()); oldValue.setVersion(value.getVersion() + 1); } } @Component("optimisticTest1") @Scope("prototype") public class ValueTaskWithOptimisticControl implements ValueTask { //    @Override public void run() { try { startLatch.await(); } catch (InterruptedException e2) { Thread.currentThread().interrupt(); } while (!Thread.currentThread().isInterrupted()) { Value value = null; //  try { value = valueDao.loadValue(id); } catch (NestedRuntimeException e) { continue; } value.setField2(value.getField2().add(BigDecimal.ONE)); //     try { valueDao.storeValue(value); countOfChanges++; } catch (NestedRuntimeException e) { //  try { Thread.sleep(300); } catch (InterruptedException e1) { Thread.currentThread().interrupt(); break; } continue; } } finishLatch.countDown(); } } 

निराशावादी ऑफ़लाइन लॉक कार्यान्वयन कोड

 @Repository("pessimisticDao") @Scope("prototype") public class ValueDaoWithPessimisticControl implements ValueDao { //    @Transactional @Override public Value loadValue(Integer id) { //          Value value = (Value) sessionFactory.getCurrentSession().get( Value.class, id, new LockOptions(LockMode.PESSIMISTIC_WRITE) ); if (value.isLocked()) throw new PessimisticLockingFailureException("Value have already locked"); value.setLocked(true); return value; } @Transactional @Override public void storeValue(Value value) { //          Value oldValue = (Value) sessionFactory.getCurrentSession().get( Value.class, value.getId(), new LockOptions(LockMode.PESSIMISTIC_WRITE) ); if (!oldValue.isLocked()) throw new PessimisticLockingFailureException("Value have not locked"); oldValue.setField1(value.getField1()); oldValue.setField2(value.getField2()); oldValue.setLocked(false); } } @Component("pessimisticTest1") @Scope("prototype") public class ValueTaskWithPessimisticControl implements ValueTask { //    @Override public void run() { try { startLatch.await(); } catch (InterruptedException e2) { Thread.currentThread().interrupt(); } while (!Thread.currentThread().isInterrupted()) { Value value = null; //    . //       . while (value == null) { try { value = valueDao.loadValue(id); } catch (NestedRuntimeException e) { try { Thread.sleep(300); } catch (InterruptedException e1) { Thread.currentThread().interrupt(); break; } } } if (value == null) continue; value.setField2(value.getField2().add(BigDecimal.ONE)); try { valueDao.storeValue(value); countOfChanges++; } catch (NestedRuntimeException e) { continue; } } finishLatch.countDown(); } } 

हर कोई जो पूर्ण परीक्षण कोड में रुचि रखता है, संग्रह डाउनलोड कर सकता है और अपने दम पर प्रयोग कर सकता है। प्रोजेक्ट को बनाने के लिए, maven 3 का उपयोग किया जाता है। आप प्रोजेक्ट डायरेक्टरी से निम्नलिखित कमांड के साथ टेस्ट चला सकते हैं:

 export MAVEN_OPTS=-server mvn exec:java -Dexec.mainClass="concurrency.patterns.Application" \ -Dexec.args="-time ___ \ -concurrency_rate _ -id _ -action _" 

एक साथ पहुंच के विभिन्न स्तरों (10 सेकंड के निष्पादन अंतराल के लिए दिए गए) के परीक्षणों के परिणाम नीचे दिए गए ग्राफ़ में प्रस्तुत किए गए हैं। माप 4-कोर सीपीयू पर किए गए थे।



सच कहूँ तो, मेरे लिए यह परिणाम थोड़ा अप्रत्याशित था। मैं निराशावादी ऑफ़लाइन लॉक के क्षरण की बहुत कम डिग्री पर गिन रहा था। इन परिणामों के अनुसार, यह स्पष्ट है कि दोनों दृष्टिकोणों में गिरावट का एक तुलनीय स्तर है। पहले परीक्षण के क्रियान्वयन में, एक ओवरसाइट के कारण, मैंने लॉकिंग कैप्चर के साथ ValueDaoWithOptimisticControl वर्ग में डेटा लोड किया, जिसके कारण ऑप्टिमिस्टिक ऑफ़लाइन लॉक कार्यान्वयन का अधिक क्षरण हुआ। अंतिम कार्यान्वयन में, पेसिमिस्टिक ऑफ़लाइन लॉक में कार्रवाई करने के लिए बड़ी संख्या में डेटाबेस क्वेरी के कारण गिरावट होती है। समवर्ती अभिगम नियंत्रण के निराशावादी प्रकार के साथ, डेटाबेस में 4 प्रश्न किए जाते हैं (2 अपडेट के लिए चयन करें और 2 अपडेट इंस्टॉल और अनलॉक करें), जबकि एक आशावादी 3 प्रश्न (1 चयन, 2 अपडेट और अपडेट के लिए चयन करें)। दरअसल, प्रदर्शन का पूरा अंतर अनुरोधों में अंतर के कारण होता है, क्योंकि यह उन पर खर्च किया जाने वाला मुख्य समय है। वास्तव में, दोनों दृष्टिकोण डेटाबेस में एक पंक्ति पर एक कार्रवाई के निष्पादन का क्रमांकन प्रदान करते हैं, और इसलिए अंतिम परिणाम एक कार्रवाई के निष्पादन समय से विभाजित परीक्षण निष्पादन समय के लगभग बराबर है। व्यवहार में मुख्य अंतर बिना किसी गारंटी के एक कार्रवाई का निष्पादन है जो परिणाम सहेजा जाएगा। दूसरे शब्दों में, वैकल्पिक संसाधन की खपत। ऐसा व्यवहार एक आशावादी प्रकार के नियंत्रण की विशेषता है। यह असामान्य समाप्ति के दौरान कब्जे वाले संसाधनों को मुक्त करने की आवश्यकता की कमी के लिए एक शुल्क है।

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

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

दुर्घटना के दौरान संसाधनों पर कब्जा [निराशावादी ऑफ़लाइन ताला]

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

ईवेंट को लॉक करें

जाहिर है, लॉक को रीसेट करने के लिए, जिसके मालिक को ट्रेस के बिना गायब हो गया, किसी प्रकार के उत्तेजक संकेत (घटना) की आवश्यकता है। इस तरह की घटना हो सकती है, उदाहरण के लिए: क्लाइंट से एक डिस्कनेक्शन, लॉक को रखने के लिए समय अवधि की समाप्ति, या सिस्टम की सेवा करने वाले उपयोगकर्ता की कार्रवाई।

कनेक्शन ड्रॉप ट्रैकिंग दृष्टिकोण तब लागू होता है जब क्लाइंट और एप्लिकेशन सर्वर एक प्रोटोकॉल के माध्यम से संपर्क करते हैं जो कनेक्शन स्थिति का समर्थन करता है। कनेक्शन राज्य के लिए किस स्तर पर लागू किया जाएगा, इस संदर्भ में विशेष रूप से महत्वपूर्ण नहीं है। यह या तो tcp कनेक्शन विराम या एक वेब क्लाइंट सत्र स्थिति को ट्रैक कर सकता है।

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

दो वर्णित दृष्टिकोणों को एक मिश्रित रूप में जोड़ा जा सकता है, जहां एक निश्चित अंतराल पर क्लाइंट को सिग्नल भेजकर या लॉक कैप्चर टाइमस्टैम्प को अपडेट करके कनेक्शन की स्थिति की निगरानी की जा सकती है।

निराशावादी दृष्टिकोण का उपयोग न करें

यह आम बात नहीं है, लेकिन संसाधनों की रिहाई के साथ समस्या को केवल उन पर कब्जा किए बिना हल किया जा सकता है। एक साथ पहुंच को नियंत्रित करने के लिए, आप ऑप्टिमिस्टिक ऑफ़लाइन लॉक का उपयोग कर सकते हैं, या यहां तक ​​कि ताले को छोड़ सकते हैं और बाद के सभी के आधार पर डेटा को अपडेट कर सकते हैं जो पिछले सभी को मिटा देता है। लेकिन दूसरा विकल्प सार्वभौमिक नहीं है और इसका उपयोग केवल कुछ वर्गों के अनुप्रयोगों के साथ किया जा सकता है। इसके अलावा, गैर-अवरुद्ध एल्गोरिदम बहुत जटिल हैं और एक उच्च समर्थन लागत है। गैर-अवरुद्ध दृष्टिकोण के विकल्प का उपयोग वास्तव में उचित प्रदर्शन आवश्यकताओं के साथ एक निकास के रूप में किया जाना चाहिए।

PoEAA समानांतर प्रोग्रामिंग पैटर्न लागू करना

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

पीओएएए समानांतर प्रोग्रामिंग पैटर्न का सामान्य उद्देश्य व्यवसाय परत स्तर पर एक साथ पहुंच की समस्याओं को हल करना है। यही है, एक अलग सिंक्रनाइज़ेशन तंत्र का निर्माण। इसके बावजूद, उनके सही कार्यान्वयन के लिए डीबीएमएस प्रदान करने वाले निम्न-स्तरीय तंत्रों को समझना आवश्यक है: ताले, लेनदेन अलगाव।

अतिरिक्त स्रोत

परीक्षण एप्लिकेशन के कोड के साथ पुरालेख
निराशावादी ऑफ़लाइन ताला
आशावादी ऑफ़लाइन लॉक