9

जब आप दौड़ की स्थिति के तहत कोड काम करना चाहते हैं, तो आमतौर पर डेवलपर आशावादी समेकन नियंत्रण (ओसीसी) का उपयोग करता है। विकिपीडिया से:इवेंट सोर्सिंग और आशावादी समेकन नियंत्रण

... करने से पहले, प्रत्येक लेनदेन सत्यापित करता है कि कोई अन्य लेनदेन ने जो डेटा पढ़ा है उसे संशोधित किया है। जांच परस्पर विरोधी संशोधनों का पता चलता है, तो करने से लेन-देन वापस रोल ...

एक दृष्टिकोण को लागू करने के OCC जाँच कर रहा है डेटा की एक version संशोधित करने की। यदि संस्करण अलग है, तो अन्य लेन-देन ने डेटा को संशोधित किया है और यह निर्णय लेने के लिए कि यह कैसे संघर्ष को हल करना चाहिए (पुनः प्रयास, उपयोगकर्ता को सूचित करें ...)।

एक मसौदे पर निम्नलिखित के रूप में होगा:

class Repository 
{ 
    public class save($data) 
    { 
     $currentVersion = $data->version; 
     $data->version = $currentVersion + 1; 

     $result = $this->db->update($data, [ 
      'id'  => $data->id, 
      'version' => $currentVersion 
     ]); 

     if (1 === $result) { 
      // everything ok 
     } else { 
      // conflict! 
     } 
    } 
} 

मेरे सवाल है, EventSourcing में के रूप में हम केवल संलग्न सभी घटनाओं है कि डोमेन में होता है, हम अब OCC लागू करने के लिए इस दृष्टिकोण का उपयोग नहीं कर सकते । EventSourcing का उपयोग करते समय ओओसी रखने के लिए अन्य दृष्टिकोण कौन से हैं?

एक विकल्प जो काम कर सकता है, यह उन्हें संग्रहीत करते समय विरोधाभासी घटनाओं के लिए खोज रहा है। यह दृष्टिकोण घटनाओं पर एक बढ़िया दाग नियंत्रण की अनुमति देता है। मुझे नहीं पता कि यह समाधान को जटिल करेगा या नहीं, यह एक "मानक" है जो मुझे लगता है कि http://danielwhittaker.me/2014/09/29/handling-concurrency-issues-cqrs-event-sourced-system/

समस्या विवरण में किसी भी अंतर की सराहना की जाती है। अग्रिम में धन्यवाद!

उत्तर

10

किसी ईवेंट को किसी ईवेंट में जोड़ने की कोशिश करने पर, आप एक अपेक्षित वर्तमान संस्करण संख्या निर्दिष्ट कर सकते हैं और वास्तविक वर्तमान संख्या से मेल नहीं खाते हैं।

इस प्रकार की आशावादी समेकन तंत्र built into कुछ ईवेंट स्टोरेज सिस्टम है।

आपके द्वारा लिंक किया गया लेख एक समान दृष्टिकोण का वर्णन करता है लेकिन अधिक शक्तिशाली है क्योंकि आपके पास अपेक्षित संस्करण के बाद हुई घटनाओं के प्रकार तक पहुंच है और अधिक बढ़िया मानदंडों के आधार पर संघर्ष का पता लगा सकता है।

2

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

0

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

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

कृपया यह भी ध्यान रखें कि आपके ईवेंट स्टोर को आपको अद्वितीय इंडेक्स का उपयोग करने की अनुमति देनी चाहिए, इस मामले में आरडीबीएमएस टेबल सबसे अच्छा विकल्प है।

संबंधित मुद्दे