👂 🏐 👨🏾‍⚕️ जेपीए में अद्भुत संस्करण एनोटेशन 🙎🏿 👨🏾‍🏫 👨🏾‍🔧

परिचय

तो चलिए शुरू करते है! जेपीए में संस्करण एनोटेशन का क्या अर्थ है?

संक्षेप में, वह जेपीए में अवरोध के लिए जिम्मेदार है। यह एनोटेशन उन समस्याओं में से एक को हल करता है जो समानांतर लेनदेन के परिणामस्वरूप उत्पन्न हो सकती हैं।

क्या समस्याएं पैदा हो सकती हैं?

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

उनके फैसलों के बारे में संक्षेप में

READ UNCOMMITED - JPA में संस्करण एनोटेशन का उपयोग करके हल किया गया (यह बिल्कुल लेख है)
पढ़ें टिप्पणी - केवल पढ़ने के लिए प्रतिबद्ध परिवर्तन की अनुमति देता है
पुनरावर्ती पढ़ें - यहां थोड़ा अधिक जटिल है। हमारा लेनदेन "उस डेटा में परिवर्तन नहीं देखता है जो पहले पढ़ा था, और अन्य लेनदेन हमारे लेनदेन में गिरे डेटा को बदल नहीं सकते हैं।"
अनुक्रमिक - अनुक्रमिक लेनदेन निष्पादन

प्रत्येक बाद का पैराग्राफ पिछले सभी को शामिल करता है, दूसरे शब्दों में, यह पहले बताए गए समाधानों को बदल सकता है। इस प्रकार, SERIALIZABLE में उच्चतम अलगाव स्तर है, और READ UNCOMMITED में सबसे कम है।

संस्करण

संस्करण खो अद्यतन के साथ समस्या हल करती है। कैसे ठीक है, अब हम देखेंगे।

कोड पर जाने से पहले, यह ध्यान देने योग्य है कि दो प्रकार के ताले हैं: आशावादी और निराशावादी । अंतर यह है कि पूर्व को उन स्थितियों द्वारा निर्देशित किया जाता है जिसमें कई लेनदेन एक ही समय में एक क्षेत्र को बदलने की कोशिश करते हैं, बहुत कम ही उत्पन्न होते हैं, जबकि अन्य विपरीत स्थिति से निर्देशित होते हैं। इसके अनुसार, उनके निष्पादन तर्क में अंतर है।

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

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

निराशावादी लोगों में , सभी लाइनों पर कथित डेटा संशोधन से तुरंत पहले ताला लगाया जाता है, जो इस तरह के संशोधन को प्रभावित करता है।

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

LockModeType या लॉक कैसे सेट करें

EntityManager के लुक मेथड को कॉल करके लॉक सेट किया जा सकता है।

entityManager.lock(myObject, LockModeType.OPTIMISTIC);

LockModeType एक लॉकिंग रणनीति को परिभाषित करता है।

LockModeType 6 प्रकार के हो सकते हैं (जिनमें से 2 आशावादी हैं , और 3 निराशावादी हैं ):

कोई नहीं - कोई ताला नहीं
आशावादी
OPTIMISTIC_FORCE_INCREMENT
PESSIMISTIC_READ
PESSIMISTIC_WRITE
PESSIMISTIC_FORCE_INCREMENT

हमारी इकाई बनाएँ

 import lombok.Getter; import lombok.Setter; import javax.persistence.*; @EntityListeners(OperationListenerForMyEntity.class) @Entity public class MyEntity{ @Version private long version; @Id @GeneratedValue @Getter @Setter private Integer id; @Getter @Setter private String value; @Override public String toString() { return "MyEntity{" + "id=" + id + ", version=" + version + ", value='" + value + '\'' + '}'; } }

आइए एक वर्ग बनाएं जहां सभी कॉलबैक विधियों को लागू किया जाएगा।

 import javax.persistence.*; public class OperationListenerForMyEntity { @PostLoad public void postLoad(MyEntity obj) { System.out.println("Loaded operation: " + obj); } @PrePersist public void prePersist(MyEntity obj) { System.out.println("Pre-Persistiting operation: " + obj); } @PostPersist public void postPersist(MyEntity obj) { System.out.println("Post-Persist operation: " + obj); } @PreRemove public void preRemove(MyEntity obj) { System.out.println("Pre-Removing operation: " + obj); } @PostRemove public void postRemove(MyEntity obj) { System.out.println("Post-Remove operation: " + obj); } @PreUpdate public void preUpdate(MyEntity obj) { System.out.println("Pre-Updating operation: " + obj); } @PostUpdate public void postUpdate(MyEntity obj) { System.out.println("Post-Update operation: " + obj); } }

Main.java

 import javax.persistence.*; import java.util.concurrent.*; //        ,   . public class Main { //  , ..  EntityManagerFactory  ,     . private static EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("ru.easyjava.data.jpa.hibernate"); public static void main(String[] args) { //  10 (  ,       ). ExecutorService es = Executors.newFixedThreadPool(10); try { //  persistFill()   - . persistFill(); for(int i=0; i<10; i++){ int finalI = i; es.execute(() -> { //      updateEntity(finalI) ,  java       .    java -  ,      id,       , id    ,       (  ,      persistFill(),  id       500). updateEntity(finalI); }); } es.shutdown(); try { es.awaitTermination(10, TimeUnit.SECONDS); } catch (InterruptedException e) { e.printStackTrace(); } } finally { entityManagerFactory.close(); } } //         . private static void updateEntity(int index) { //  EntityManager  ,     ,    . EntityManager em = entityManagerFactory.createEntityManager(); MyEntity myEntity = null; try { em.getTransaction().begin(); //        1. myEntity = em.find(MyEntity.class, 1); //   sout,       "" . System.out.println("load = "+index); //       (  LockModeType.*). em.lock(myEntity, LockModeType.OPTIMISTIC); //   Value,  ,        . myEntity.setValue("WoW_" + index); em.getTransaction().commit(); em.close(); System.out.println("--Greeter updated : " + myEntity +" __--__ "+ index); }catch(RollbackException ex){ System.out.println(", =" + myEntity); } } public static void persistFill() { MyEntity myEntity = new MyEntity(); myEntity.setValue("JPA"); EntityManager em = entityManagerFactory.createEntityManager(); em.getTransaction().begin(); em.persist(myEntity); em.getTransaction().commit(); em.close(); } }

टिप्पणी अद्यतन विधि के साथ पहली बार चलाएँ

 Pre-Persistiting operation: MyEntity{id=null, version=0, value='JPA'} Post-Persist operation: MyEntity{id=531, version=0, value='JPA'}  .  id   find   .

LockModeType.OPTIMISTIC

यह एक आशावादी ब्लॉक है, ठीक है, यह बहुत तार्किक है। जैसा कि मैंने ऊपर लिखा था, संस्करण फ़ील्ड के मूल्य की तुलना की जाती है; अगर यह अलग है, तो एक त्रुटि फेंक दी जाती है। इसे देखें।

परिणाम:

 Loaded operation: MyEntity{id=531, version=0, value='JPA'} load = 3 Loaded operation: MyEntity{id=531, version=0, value='JPA'} load = 2 Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_2'} Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_3'} Loaded operation: MyEntity{id=531, version=0, value='JPA'} load = 9 Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_9'} Loaded operation: MyEntity{id=531, version=0, value='JPA'} load = 1 Pre-Updating operation: MyEntity{id=531, version=0, value='WoW_1'} Post-Update operation: MyEntity{id=531, version=1, value='WoW_1'} --Greeter updated : MyEntity{id=531, version=1, value='WoW_1'} __--__ 1 , =MyEntity{id=531, version=0, value='WoW_2'} , =MyEntity{id=531, version=0, value='WoW_3'} Loaded operation: MyEntity{id=531, version=1, value='WoW_1'} load = 4 Pre-Updating operation: MyEntity{id=531, version=1, value='WoW_4'} Post-Update operation: MyEntity{id=531, version=2, value='WoW_4'} --Greeter updated : MyEntity{id=531, version=2, value='WoW_4'} __--__ 4 , =MyEntity{id=531, version=0, value='WoW_9'} Loaded operation: MyEntity{id=531, version=2, value='WoW_4'} load = 0 Pre-Updating operation: MyEntity{id=531, version=2, value='WoW_0'} Post-Update operation: MyEntity{id=531, version=3, value='WoW_0'} --Greeter updated : MyEntity{id=531, version=3, value='WoW_0'} __--__ 0 Loaded operation: MyEntity{id=531, version=3, value='WoW_0'} load = 6 Pre-Updating operation: MyEntity{id=531, version=3, value='WoW_6'} Post-Update operation: MyEntity{id=531, version=4, value='WoW_6'} Loaded operation: MyEntity{id=531, version=4, value='WoW_6'} load = 5 Pre-Updating operation: MyEntity{id=531, version=4, value='WoW_5'} Post-Update operation: MyEntity{id=531, version=5, value='WoW_5'} --Greeter updated : MyEntity{id=531, version=4, value='WoW_6'} __--__ 6 --Greeter updated : MyEntity{id=531, version=5, value='WoW_5'} __--__ 5 Loaded operation: MyEntity{id=531, version=5, value='WoW_5'} load = 7 Pre-Updating operation: MyEntity{id=531, version=5, value='WoW_7'} Post-Update operation: MyEntity{id=531, version=6, value='WoW_7'} Loaded operation: MyEntity{id=531, version=5, value='WoW_5'} load = 8 Pre-Updating operation: MyEntity{id=531, version=5, value='WoW_8'} --Greeter updated : MyEntity{id=531, version=6, value='WoW_7'} __--__ 7 , =MyEntity{id=531, version=5, value='WoW_8'}

अवलोकन: जैसा कि आप परिणामों से देख सकते हैं, धारा 3, 2, 9, और 1 पहले लोड करने के लिए थे, और प्री-अपडेट कॉलबैक विधियों को उनके लिए बुलाया गया था। पहला थ्रेड जहां पोस्ट-अपडेट विधि को कॉल किया गया था वह 1 था, जैसा कि आप परिणामों से देख सकते हैं, संस्करण एनोटेशन के साथ चिह्नित फ़ील्ड को पहले ही बदल दिया गया है (1 से बढ़ कर)। तदनुसार, सभी बचे हुए धागे 2, 3, 9 ने एक अपवाद फेंक दिया। और इसी तरह। परिणाम मूल्य = WoW_7, संस्करण = 6. वास्तव में, अंतिम पोस्ट-अपडेट संस्करण 7 में संस्करण = 6 के साथ था।

LockModeType.OPTIMISTIC_FORCE_INCREMENT

यह LockModeType.OPTIMISTIC के समान एल्गोरिथ्म के अनुसार काम करता है, सिवाय इसके कि संस्करण क्षेत्र के मूल्य के बाद जबरन 1 से बढ़ा दिया जाता है। परिणामस्वरूप, प्रत्येक प्रतिबद्ध के बाद, फ़ील्ड 2 से बढ़ जाएगी (वृद्धि जो पोस्ट-अपडेट + मजबूर वृद्धि में देखी जा सकती है) । प्रश्न। क्यों? यदि एक प्रतिबद्ध के बाद भी हम इस डेटा को "कंज्यूम" करना चाहते हैं, और हमें तीसरे पक्ष के लेनदेन की आवश्यकता नहीं है, जो पहले कमिट और हमारे लेनदेन को बंद करने के बीच टूट सकता है।

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

LockModeType.PESSIMISTIC_READ, LockModeType.PESSIMISTIC_WRITE और LockModeType.PESSIMISTIC_FORCE_INCREMENT

चूंकि शेष प्रकार के तालों का काम समान दिखता है, इसलिए मैं एक ही बार में लिखूंगा और केवल PESSIMISTIC_READ द्वारा परिणाम पर विचार करूंगा।

LockModeType.PESSIMISTIC_READ - निराशावादी लॉक पढ़ें।
LockModeType.PESSIMISTIC_WRITE - निराशावादी लेखन ताला (और पढ़ें)।
LockModeType.PESSIMISTIC_FORCE_INCREMENT - निराशावादी लेखन लॉक (और पढ़ें) संस्करण क्षेत्र की मजबूर वृद्धि के साथ।

इस तरह के ताले के परिणामस्वरूप, एक ताला के लिए एक लंबा इंतजार हो सकता है, जिसके परिणामस्वरूप एक त्रुटि हो सकती है।

LockModeType.PESSIMISTIC_READ पर परिणाम (इसकी संपूर्णता में प्रस्तुत नहीं):

 load = 0 Pre-Updating operation: MyEntity{id=549, version=5, value='WoW_0'} Post-Update operation: MyEntity{id=549, version=6, value='WoW_0'} Loaded operation: MyEntity{id=549, version=6, value='WoW_0'} load = 8 Pre-Updating operation: MyEntity{id=549, version=6, value='WoW_8'} Loaded operation: MyEntity{id=549, version=6, value='WoW_0'} load = 4 Pre-Updating operation: MyEntity{id=549, version=6, value='WoW_4'} ... ERROR: :   :  22760    ExclusiveLock  " (0,66)  287733   271341";   20876.  20876    ShareLock  " 8812";   22760.

नतीजतन, थ्रेड्स 4 और 8 ने एक दूसरे को अवरुद्ध कर दिया, जिससे एक असहनीय संघर्ष हुआ। इससे पहले, किसी ने धागा 0 के साथ हस्तक्षेप नहीं किया। सभी धागे के साथ एक समान स्थिति 0 तक।

जेपीए में अद्भुत संस्करण एनोटेशन