Database Transaction in ADO.Net हमें Database में Stored Data के साथ Interaction करने की सुविधा Provide करता है। Multi-User Scenario में अथवा Single User Scenario में, जिसमें कि बहुत सारे Processes, Threads व Entities Underlying Database को Change कर रहे होते हैं। साथ ही कुछ स्थितियों में हम स्वयं एक ही समय पर एक से ज्यादा Statements Execute करते हुए Underlying Database को Change करते हैं। इसलिए ये सम्भावना बहुत ज्यादा रहती है कि Database का Data एक दूसरे के ऊपर Overlap होकर Corrupt या Inaccurate हो जाए।
उदाहरण के लिए जब हम ATM Machine से Payment Withdraw करना चाहते हैं, तब हम क्रम से बहुत सारे Steps को Follow करते हैं। यानी हम हमारे ATM Card को ATM Machine में Insert करते हैं, Security Code Type करते हैं, Account Selection करते हैं, Payment Specify करते हैं और अन्त में Payment Receive करने के बाद Receipt प्राप्त करते हैं। इन सभी Steps में से किसी भी Step के पूरा न होने की स्थिति में Transaction Fail हो जाता है।
यानी यदि सभी काम हो जाऐं, लेकिन अन्त में Payment हमें प्राप्त न हो, तो भी पूरा Transaction Fail हो जाना चाहिए अन्यथा हमारे Account से तो Payment Reduce हो जाएगा, जबकि हमें Payment प्राप्त नहीं होगा। इस प्रकार की स्थिति जिसमें या तो सभी काम पूरी तरह से पूरे हों अथवा कोई भी काम पूरा न हो बल्कि जो काम हो चुके हैं, वे भी Rollback हो जाऐं, Transaction कहलाता है और कई बार हमें हमारे Program में भी इस व्यवस्था को Apply करना ही होता है।
.NET Framework हमें System.Transactions नाम का एक Namespace Provide करता है, जिसका प्रयोग करके हम ऐसे Codes Create करते हैं, जिनके सभी Statements का Compulsory रूप से Execute होना जरूरी होता है। जब सभी Specified Statements बिना किसी Error के Normal तरीके से Execute होते हैं, तभी उस Transaction को Complete माना जा सकता है। अन्यथा Transaction के किसी भी Statement के Fail होने की स्थिति में पूरा Transaction Rollback कर दिया जाना होता है, ताकि Database फिर से अपनी उस पुरानी स्थिति में पहुंच जाए, जहां Transaction Perform होना शुरू होने से पहले था।
What is Transaction in Programming
यदि हम Programming के लिहाज से समझें, तो Transaction वास्तव में Operations का एक Set होता है, जिसके अन्तर्गत या तो सभी Operations पूरी तरह से Successfully Execute होते हैं, अथवा एक भी Operation के Fail होने की स्थिति में सभी Operation Rollback हो जाते हैं, यानी कोई भी Operation Perform नहीं होता। परिणामस्वरूप Multiuser Environment में भी Application की Consistency बनी रहती है।
सामान्यत: Transactions को कुछ Guidelines को Follow करना जरूरी होता है, जिन्हें ACID Properties के रूप में जाना जाता है। ये ACID Properties इस बात को निि”चत करते हैं कि Complex Transactions भी Self-Contained व Reliable रहेंगे।
ACID Properties
Transactions की मुख्यत: चार Properties होती हैं जिन्हें Atomic, Consistent, Isolated व Durable नाम से जाना जाता है। यानी किसी भी Transaction को हमेंशा ACID Test Pass करना जरूरी होता है, तभी वह Transaction Normal तरीके से काम कर सकता है। इन ACID Properties को निम्नानुसार ज्यादा बेहतर तरीके से समझा जा सकता है:
Atomic
पूरा Transaction एक Unit के रूप में काम करना चाहिए। यानी या तो Transaction के सभी Operations बिना किसी Error के Successfully Execute होने चाहिए अथवा किसी भी Operation के Fail होने की स्थिति में पूरा Transaction Fail होना चाहिए। जब तक किसी Transaction के सभी Steps पूरी तरह से Successfully Execute नहीं हो जाते, तब तक हम Transaction को Complete नहीं मान सकते।
Consistent
Transaction हमेंशा Underlying Database को एक Stable स्थिति से दूसरी Stable स्थिति में ले जाना चाहिए।
Isolated
हर Transaction एक Independent Entity होना चाहिए। यानी कोई भी Transaction किसी भी अन्य Transaction को, जो कि समानान्तर रूप से Run हो रहा हो, Disturb या प्रभावित नहीं करना चाहिए।
Durable
Transaction द्वारा Underlying Database में जो भी Changes किए जाते हैं, वे सभी Changes किसी न किसी Secondary Media जैसे कि Hard Disk Drive में Permanently Save होने के बाद ही Transaction Successful Declare होता है।
ये चारों Characteristics किसी भी Transaction की Ideal Characteristics हैं। हालांकि इनमें से कुछ Characteristics को जरूरत के आधार पर Modify भी किया जाता है। जैसे कि Isolation Property के अनुसार एक Transaction किसी दूसरे Transaction को प्रभावित नहीं कर सकता।
लेकिन कई बार ऐसी जरूरत पडती है, जब हमें किसी एक Transaction द्वारा Generate होने वाले Result को Continually किसी दूसरे Transaction में Use करना होता है। इस स्थिति में दो Transactions एक दूसरे को प्रभावित कर सकते हैं, जो कि पूरी तरह से हमारी जरूरत पर निर्भर करता है। साथ ही हम एक Transaction के अन्दर किसी दूसरे Transaction की Nesting भी कर सकते हैं।
Database Transactions
Transactions का प्रयोग सामान्यत: विभिन्न प्रकार के Business Applications में किया जाता है, क्योंकि इनका प्रयोग करके हम हमारे Database Application को ज्यादा Reliable System के रूप में Develop करने की सुविधा प्राप्त करते हैं।
जब हम कोई Database Application Develop करते हैं, तो Data को Store करने के लिए किसी न किसी तरह के Underlying DataSource की जरूरत होती है। इस प्रकार के Database Application में ये जरूरी होता है कि हमारा Underlying Data Source Transaction को Support करे, तभी हम ADO.NET के Transactions Concept को इस प्रकार के Database पर Apply कर सकते हैं।
चूंकि वर्तमान समय में उपलब्ध सभी Modern Data Source जैसे कि MSSQL Server, Oracle, DB2 आदि पूरी तरह से Transactions को Support करते हैं, इसलिए यदि हम इनमें से किसी Data Source को अपने Database Application के Backend के रूप में Use करते हैं, तो हमें किसी प्रकार का Extra Test करने की जरूरत नहीं होती।
उदाहरण के लिए यदि हम SQL Server की बात करें, तो MSSQL Server हमें T-SQL Statements के रूप में BEGIN TRANSACTION, SAVE TRANSACTION, COMMIT TRANSACTION व ROLLBACK TRANSACTION Provide करता है।
ODBC, OleDb व ADO.NET जैसे Data Access APIs हमें एक Developer के रूप में अपने Database Application में Transactions को Use करने की सुविधा Provide करते हैं। सामान्यत: RDBMS व Data Access APIs हमें तब तक Transaction Support Provide करते हैं, जब तक कि हम Single Database के साथ काम कर रहे होते हैं।
जबकि बहुत ही ज्यादा बडे Database Applications में बहुत सारे Database Involved होते हैं। उस स्थिति में हमें Multi-Database Transactional Support प्राप्त करने के लिए Microsoft Distributed Transaction Coordinator (MSDTC) को Use करने की जरूरत पडती है। Microsoft Transaction Server (MTS) व COM+ भी MSDTC को Internally Use करते हुए ही Multi-Database Transactions Support Provide करते हैं।
Local and Distributed Transactions
Transactions को Local व Distributed के रूप में हम दो भागों में विभाजित कर सकते हैं। Local Transaction हमेंशा एक Transaction-Aware Data Source Use करता है और केवल एक Single Transaction में ही इसका Scope होता है। जब एक Single Database ही Transaction में Involved सभी Data को Hold करता है, तो ये स्वयं पर ACID Rules को Enforce करता है। इसका मतलब ये है कि SQL Server जैसे Single Database Server पर हम Local Transactions को समान Connection का प्रयोग करते हुए Use कर सकते हैं।
जबकि Distributed Transactions के अन्तर्गत एक Transaction कई Transaction-Aware Data Source के बीच विभाजित होता है और उस Transaction के Execute होने पर एक से ज्यादा Databases के Data प्रभावित होते हैं। इस प्रकार के Transactions को SQL Server या अन्य Databases से Data Retrieve या Save करने के लिए Message Queue Server की जरूरत होती है।
Manual and Automatic Transactions
Transactions को यदि हम चाहें तो एक और तरीके से विभाजित कर सकते हैं, जिसके अन्तर्गत Transactions को Automatic Transaction या Manual Transaction के नाम से जाना जाता है। Manual Transaction Model हमें Manually किसी Transaction को BEGIN व END करने की सुविधा Provide करता है।
इस प्रकार के Transaction में हम स्वयं अपनी जरूरत व सुविधानुसार Transaction को शुरू करते हैं और उस Transaction के माध्यम से Execute होने वाले Statements को Specify करने के बाद Transaction का अन्त करते हैं। इस प्रकार के Transaction में हम किसी Running Transaction में नए Transaction को भी Start कर सकते हैं। यानी हम Transactions की Nesting भी कर सकते हैं।
ADO.NET हमें SqlConnection, SqlTransaction जैसे कई Objects Provide करता है, जिनका प्रयोग करके हम Application Level पर किसी Transaction को Create, Begin, Commit, Rollback व Close कर सकते हैं।
जबकि Automatic Transaction Model में Transaction स्वयं ही एक या अधिक Statement के Around Wrap होता है। अन्य शब्दों में कहें तो Additional Statements सामान्यत: Currently Run होने वाले Transaction में Automatically Enlist होते हैं।
यदि हमारा Transaction एक से ज्यादा Databases के बीच Distributed हो, तो उस स्थिति में Automatic Transaction ही हमारे लिए सबसे बेहतर Option होता है। यानी Distributed Transaction होने की स्थिति में हमें Transaction को Manually Handle करने की कोशिश नहीं करनी चाहिए।
Transaction related Commands
किसी भी Database Transaction से सन्दर्भ में कुछ निश्चित Commands का बहुतायत से प्रयोग किया जाता है, जो कि BEGIN, COMMIT, SAVE व ROLLBACK हैं। ये Commands किसी भी Transaction को Implement करने के लिए उपयोग में लिए जाते हैं। इन सभी Commands का अपना एक निि”चत काम होता है, जो कि निम्नानुसार है:
BEGIN
किसी Transaction में Specify किए गए विभिन्न Statements के Execute होना शुरू होने से पहले Transaction को Initialize करना जरूरी होता है, ताकि हमारा Computer System इस बात को त; कर सके कि हमारा Transaction कहां से शुरू हो रहा है।
COMMIT
जब किसी Transaction में Specified सभी Statements Successfully Execute हो जाते हैं, तो Transaction द्वारा Underlying Database में जिन Changes को Perform किया जाता है, उन्हें पूरी तरह से Permanently Save करने का काम इस Command द्वारा किया जाता है। इस Command के Execute होने के बाद यदि ROLLBACK Command को Use किया जाए, तो भी Underlying Database Last COMMIT Comment से Back नहीं जाता।
SAVE
इस Command का प्रयोग करके हम हमारे Transaction में जग-जगह पर जरूरत के अनुसार Save Points या Markers Set करते हैं। ताकि किसी Specific Statement के Fail होने की स्थिति में पूरा Transaction Rollback करने के स्थान पर किसी Specific Save Point तक के Transaction को Commit किया जा सके।
ROLLBACK
जब हमारा Transaction Execute होता है, तब किसी Specific Situation में हमें हमारे Underlying Database में किए गए Changes को Undo करना होता है। इस जरूरत को पूरा करने के लिए हम ROLLBACK Command को Use करते हैं।
Transactions के विषय में पर्याप्त जानकारी प्राप्त करने के बाद अब हम इस स्थिति में हैं कि ADO.NET द्वारा Provide किए जाने वाले Transaction Related Support के विषय में जानकारी प्राप्त कर सकें और एक Distributed व Concurrently Run होने वाला Database Application Design कर सकें।
ये Article इस वेबसाईट पर Selling हेतु उपलब्ध EBook ADO.NET with C# in Hindi से लिया गया है। इसलिए यदि ये Article आपके लिए उपयोगी रहा, तो निश्चित रूप से ये पुस्तक भी आपके लिए काफी उपयोगी साबित होगी।
ADO.NET with C# in Hindi | Page:501 | Format: PDF