वसंत में कुशल लेनदेन प्रबंधन

सभी को शुभ दिन!

खैर, महीने का अंत हमेशा तीव्र होता है, और "डेवलपर ऑन स्प्रिंग फ्रेमवर्क" की दूसरी धारा शुरू होने तक केवल एक दिन शेष है, समान रूप से सुंदर और क्रोधित यूरी द्वारा सिखाया गया एक अद्भुत और दिलचस्प पाठ्यक्रम (जैसा कि कुछ छात्र उसे आवश्यकताओं के स्तर के लिए कहते हैं। डीजेड में), तो आइए एक और सामग्री देखें जो हमने आपके लिए तैयार की है।

चलो चलते हैं।

परिचय

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

लेनदेन प्रबंधन में एक महत्वपूर्ण पहलू एक लेनदेन की सही सीमाओं का निर्धारण कर रहा है जब एक लेनदेन शुरू होना चाहिए और कब समाप्त होना चाहिए, जब डेटा को डेटाबेस में जोड़ा जाना चाहिए और कब इसे वापस पंप किया जाना चाहिए (अपवाद के मामले में)।



डेवलपर्स के लिए सबसे महत्वपूर्ण पहलू यह समझना है कि किसी एप्लिकेशन में लेनदेन प्रबंधन को सर्वोत्तम रूप से कैसे लागू किया जाए। तो आइए विभिन्न विकल्पों को देखें।

लेनदेन प्रबंधन के तरीके

लेनदेन को निम्नलिखित तरीकों से प्रबंधित किया जा सकता है:

1. कस्टम कोड लिखकर प्रोग्राम नियंत्रण

यह एक पुरानी लेनदेन प्रबंधन विधि है।

EntityManagerFactory factory = Persistence.createEntityManagerFactory("PERSISTENCE_UNIT_NAME"); EntityManager entityManager = entityManagerFactory.createEntityManager(); Transaction transaction = entityManager.getTransaction() try { transaction.begin(); someBusinessCode(); transaction.commit(); } catch(Exception ex) { transaction.rollback(); throw ex; } 

पेशेवरों :

• कोड में लेन-देन की सीमाएँ स्पष्ट हैं।

विपक्ष :

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

2. वसंत से लेन-देन प्रबंधन का उपयोग करना

स्प्रिंग दो प्रकार के लेनदेन प्रबंधन का समर्थन करता है

1. सॉफ्टवेयर ट्रांजेक्शन मैनेजमेंट : आपको प्रोग्रामिंग के माध्यम से लेनदेन का प्रबंधन करना चाहिए। यह विधि पर्याप्त लचीली है, लेकिन इसे बनाए रखना मुश्किल है।

2. डिक्लरेटिव ट्रांजैक्शन मैनेजमेंट : आप बिजनेस लॉजिक से ट्रांजैक्शन मैनेजमेंट को अलग करते हैं। आप केवल लेन-देन प्रबंधन के लिए XML- आधारित कॉन्फ़िगरेशन में एनोटेशन का उपयोग करते हैं।

हम घोषणात्मक लेनदेन का उपयोग करने की अत्यधिक सलाह देते हैं। यदि आप कारणों को जानना चाहते हैं, तो पढ़ें, अन्यथा यदि आप इस विकल्प को लागू करना चाहते हैं तो सीधे Declarative Transaction Management सेक्शन में जाएँ।

अब आइए प्रत्येक दृष्टिकोण को विस्तार से देखें।

2.1। प्रोग्रामेटिक ट्रांजैक्शन मैनेजमेंट:

स्प्रिंग फ्रेमवर्क प्रोग्रामिंग प्रोग्राम प्रबंधन के लिए दो उपकरण प्रदान करता है।

एक। TransactionTemplate (स्प्रिंग टीम द्वारा अनुशंसित) का उपयोग करना:

आइए नीचे दिए उदाहरण कोड का उपयोग करके इस प्रकार को लागू करने का तरीका देखें (कुछ परिवर्तनों के साथ स्प्रिंग प्रलेखन से लिया गया)

ध्यान दें कि कोड स्निपेट स्प्रिंग डॉक्स से लिए गए हैं।

संदर्भ Xml फ़ाइल:

 <!-- Initialization for data source --> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="com.mysql.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/TEST"/> <property name="username" value="root"/> <property name="password" value="password"/> </bean> <!-- Initialization for TransactionManager --> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean> <!-- Definition for ServiceImpl bean --> <bean id="serviceImpl" class="com.service.ServiceImpl"> <constructor-arg ref="transactionManager"/> </bean> 

Service वर्ग:

 public class ServiceImpl implements Service { private final TransactionTemplate transactionTemplate; //       PlatformTransactionManager public ServiceImpl(PlatformTransactionManager transactionManager) { this.transactionTemplate = new TransactionTemplate(transactionManager); } //       ,   ,    //       xml  this.transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_UNCOMMITTED); this.transactionTemplate.setTimeout(30); //30  ///    public Object someServiceMethod() { return transactionTemplate.execute(new TransactionCallback() { //         public Object doInTransaction(TransactionStatus status) { updateOperation1(); return resultOfUpdateOperation2(); } }); }} 

यदि कोई वापसी मूल्य नहीं है, तो एक अनाम वर्ग के साथ सुविधाजनक TransactionCallbackWithoutResult वर्ग का उपयोग करें, जैसा कि नीचे दिखाया गया है:

 transactionTemplate.execute(new TransactionCallbackWithoutResult() { protected void doInTransactionWithoutResult(TransactionStatus status) { updateOperation1(); updateOperation2(); } }); 

• TransactionTemplate वर्ग के उदाहरण थ्रेड सुरक्षित हैं, इसलिए सभी संवाद राज्य समर्थित नहीं हैं।
• TransactionTemplate आवृत्तियाँ कॉन्फ़िगरेशन स्थिति का समर्थन करती हैं, इसलिए यदि किसी वर्ग को विभिन्न सेटिंग्स (उदाहरण के लिए, एक अलग आइसोलेशन स्तर) के साथ TransactionTemplate का उपयोग करने की आवश्यकता है, तो आपको दो अलग-अलग TransactionTemplate इंस्टेंसेस बनाने की आवश्यकता होती है, हालाँकि कुछ वर्ग समान TransactionTemplate उदाहरण का उपयोग कर सकते हैं।

ख। PlatformTransactionManager कार्यान्वयन का सीधे उपयोग करना:

आइए कोड में इस विकल्प को फिर से देखें।

 <!-- Initialization for data source --> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="com.mysql.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/TEST"/> <property name="username" value="root"/> <property name="password" value="password"/> </bean> <!-- Initialization for TransactionManager --> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean> public class ServiceImpl implements Service { private PlatformTransactionManager transactionManager; public void setTransactionManager( PlatformTransactionManager transactionManager) { this.transactionManager = transactionManager; } DefaultTransactionDefinition def = new DefaultTransactionDefinition(); //     -  ,       def.setName("SomeTxName"); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); TransactionStatus status = txManager.getTransaction(def); try { //   -  } catch (Exception ex) { txManager.rollback(status); throw ex; } txManager.commit(status); } 

अब, लेन-देन प्रबंधन की अगली विधि पर जाने से पहले, आइए देखें कि किस प्रकार का लेनदेन प्रबंधन चुनना है।

प्रोग्रामेटिक और डिक्लेरेटिव ट्रांजैक्शन मैनेजमेंट के बीच चयन:

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

2.2। घोषणात्मक लेनदेन (आमतौर पर किसी भी वेब एप्लिकेशन के लगभग सभी परिदृश्यों में उपयोग किया जाता है)

चरण 1 : अपने स्प्रिंग एप्लिकेशन के संदर्भ xml फ़ाइल में लेनदेन प्रबंधक को परिभाषित करें।

 <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"/> <tx:annotation-driven transaction-manager="txManager"/> 

चरण 2 : अपने स्प्रिंग एप्लिकेशन के संदर्भ xml फ़ाइल में प्रविष्टि जोड़कर एनोटेशन समर्थन सक्षम करें।

या अपनी विन्यास फाइल में @EnableTransactionManagement जोड़ें, जैसा कि नीचे दिखाया गया है:

 @Configuration @EnableTransactionManagement public class AppConfig { ... } 

स्प्रिंग ने @Transactional इंटरफेस की तुलना में केवल विशिष्ट वर्गों (और विशिष्ट कक्षाओं के तरीकों) को @ @Transactional एनोटेशन के साथ एनोटेट करने की सिफारिश की है।

इसका कारण यह है कि आपने एनोटेशन को इंटरफ़ेस स्तर पर रखा है, और यदि आप प्रॉक्सी क्लासेस ( proxy-target-class = «true» ) या mode = «aspectj» ( mode = «aspectj» ) का उपयोग करते हैं, तो ट्रांजैक्शन पैरामीटर को प्रॉक्सी इन्फ्रास्ट्रक्चर द्वारा मान्यता प्राप्त नहीं है। और plexuses, उदाहरण के लिए लेन-देन व्यवहार लागू नहीं होगा।

चरण 3 : वर्ग (वर्ग विधि) या इंटरफ़ेस (इंटरफ़ेस विधि) में @ @Transactional एनोटेशन जोड़ें।

 <tx:annotation-driven proxy-target-class="true"> 

डिफ़ॉल्ट कॉन्फ़िगरेशन: proxy-target-class="false"

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

अब चलिए @ @Transactional एनोटेशन @Transactional बीच अंतर को @Transactional

@Transactional (isolation=Isolation.READ_COMMITTED)

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

DEFAULT : आधार डेटाबेस में डिफ़ॉल्ट आइसोलेशन स्तर का उपयोग करें।

READ_COMMITTED (फिक्स्ड डेटा पढ़ना): एक निरंतर संकेत है कि गंदे पढ़ने को रोका गया है; नॉन-रिपिटिंग रीडिंग और फैंटम रीडिंग हो सकती है।

READ_UNCOMMITTED ( अनकम्यूटेड डेटा पढ़ें): यह आइसोलेशन लेवल बताता है कि एक ट्रांजैक्शन उन डेटा को पढ़ सकता है जो अभी तक अन्य ट्रांजेक्शन से डिलीट नहीं हुए हैं।

REPEATABLE_READ (पुनरावृत्ति पढ़ें): एक निरंतर संकेत जो गंदे पढ़ने और गैर-दोहराने योग्य पढ़ने को रोकता है; प्रेत वाचन प्रकट हो सकता है।

अनुक्रमिक : स्थायी, यह दर्शाता है कि गंदे पढ़ने, गैर-दोहराने योग्य पढ़ने और प्रेत पढ़ने को रोका जाता है।

इन शब्दजाल का क्या मतलब है: "गंदे" पढ़ना, प्रेत पढ़ना या बार-बार पढ़ना?

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

@Transactional(timeout=60)

डिफ़ॉल्ट अंतर्निहित लेनदेन प्रणाली के लिए डिफ़ॉल्ट टाइमआउट है।

समय की लंबाई के बारे में tx प्रबंधक को सूचित करता है कि जब तक कि गैर-प्रतिक्रियाशील लेनदेन को वापस करने का निर्णय लेने से पहले tx निष्क्रिय न हो जाए, तब तक प्रतीक्षा करें।

@Transactional(propagation=Propagation.REQUIRED)

यदि निर्दिष्ट नहीं है, तो डिफ़ॉल्ट प्रसार व्यवहार REQUIRED ।

अन्य विकल्प REQUIRES_NEW, MANDATORY, SUPPORTS, NOT_SUPPORTED, NEVER और NESTED ।

आवश्यक

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

REQUIRES_NEW

• इंगित करता है कि हर बार लक्ष्य विधि कहा जाता है एक नया tx चलाया जाना चाहिए। यदि tx पहले से ही चल रहा है, तो एक नया शुरू करने से पहले इसे रोक दिया जाएगा।

अनिवार्य

• इंगित करता है कि लक्ष्य विधि के लिए सक्रिय tx की आवश्यकता है। यदि tx जारी नहीं रहता है, तो यह एक अपवाद को फेंकने में विफल नहीं होगा।

का समर्थन करता है

• इंगित करता है कि लक्ष्य विधि को tx के स्वतंत्र रूप से निष्पादित किया जा सकता है। यदि tx काम करता है, तो यह उसी tx में भाग लेगा। यदि tx के बिना निष्पादित किया जाता है, तो यह तब भी निष्पादित किया जाएगा यदि कोई त्रुटि नहीं है।

• डेटा प्राप्त करने वाले तरीके इस विकल्प के लिए सबसे अच्छे उम्मीदवार हैं।

NOT_SUPPORTED

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

कभी नहीं

• इंगित करता है कि लक्ष्य पद्धति एक अपवाद को फेंक देगी यदि एक लेनदेन प्रक्रिया में निष्पादित किया जाता है।
• यह विकल्प ज्यादातर मामलों में है जो परियोजनाओं में उपयोग नहीं किए जाते हैं।

@Transactional (rollbackFor=Exception.class)

डिफ़ॉल्ट मान: rollbackFor=RunTimeException.class

वसंत में, सभी एपीआई कक्षाएं एक RuntimeException फेंकती हैं, जिसका अर्थ है कि यदि कोई विधि विफल हो जाती है, तो कंटेनर हमेशा वर्तमान लेनदेन को वापस रोल करता है।

समस्या केवल जाँच अपवादों के साथ है। इस प्रकार, Checked Exception होने पर, इस पैरामीटर का उपयोग लेन-देन को वापस घोषित करने के लिए किया जा सकता है।

@Transactional (noRollbackFor=IllegalStateException.class)

संकेत मिलता है कि यदि लक्ष्य विधि इस अपवाद को उठाती है तो रोलबैक नहीं होना चाहिए।

अब, लेन-देन प्रबंधन में अंतिम लेकिन सबसे महत्वपूर्ण कदम @Transactiona l एनोटेशन पोस्ट कर रहा है। ज्यादातर मामलों में, भ्रम पैदा होता है कि एनोटेशन कहां स्थित होना चाहिए: सेवा स्तर पर या डीएओ स्तर पर?

@Transactional : सेवा या DAO स्तर?

सेवा @Transactional स्थान @Transactional लिए सबसे अच्छी जगह है, सेवा स्तर में उपयोगकर्ता संपर्क के लिए विस्तार के स्तर पर उपयोग के मामले का व्यवहार होना चाहिए, जो तार्किक रूप से लेनदेन में जाता है।

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

इसलिए, व्यवहार में, आप उन्हें कहीं भी रख सकते हैं, यह आपके ऊपर है।

इसके अलावा, यदि आप DAO लेयर में @Transactional को रखते हैं और यदि आपकी DAO लेयर को विभिन्न सेवाओं द्वारा पुन: उपयोग किया जाएगा, तो इसे DAO लेयर में रखना मुश्किल होगा, क्योंकि विभिन्न सेवाओं के लिए अलग-अलग आवश्यकताएं हो सकती हैं।

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

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

मुझे उम्मीद है कि इस लेख ने आपकी मदद की।

अंत

आपकी टिप्पणियों या प्रश्नों को देखना हमेशा दिलचस्प होता है।