1 / 18

4.3 TRANSACTION COMMUNICATION

Presented by Kireet Kokala. 4.3 TRANSACTION COMMUNICATION. Dr. Yanqing Zhang, CSc 8320. O UTLINE. P ART I : I NTRODUCTION Fundamentals ACID Properties [ R. Chow & T. Johnson, 1997 ] Two-phase Commit Protocol [M. Duckett, 1995] P ART II : C URRENT R ESEARCH

donald
Télécharger la présentation

4.3 TRANSACTION COMMUNICATION

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. © 2009 Georgia State University Presented by Kireet Kokala 4.3TRANSACTION COMMUNICATION Dr. Yanqing Zhang, CSc 8320

  2. OUTLINE • PART I: INTRODUCTION • Fundamentals • ACID Properties [R. Chow & T. Johnson, 1997] • Two-phase Commit Protocol [M. Duckett, 1995] • PART II: CURRENT RESEARCH • X/Open XA [IBM, Wikipedia, 2009] • Distributed Relational Database Architecture (DRDA) • PART III: FUTURE POTENTIAL • Open XA Virtualization • REFERENCES • Q&A © 2009 Georgia State University

  3. I:INTRODUCTION [R. Chow & T. Johnson, 1997] What is a Transaction? The basic unit of client-server process interaction in a database (dbase) system, but it is NOT limited to it (ex: it can also be used in a peer-to-peer protocol). DS Context  service oriented request-reply communication or asynchronous request(s). ACID – generally, every transaction is ACID (Atomicity-Consistency-Isolation-Durability) compliant in accordance with concurrency control and transparency in the DS. It is NOT required, but the best dbase transactions are ‘ACID friendly’. 3 © 2009 Georgia State University

  4. I:ACID [R. Chow & T. Johnson, 1997] ATOMICITY – ALL or NO operations in a transaction are performed. Transaction Recovery System – ensures atomicity and enables the all or nothing output. CONSISTENCY – consistent state is maintained before a transaction starts and after it concludes. Interleaved transactions  serial execution. 4 © 2009 Georgia State University

  5. I:ACID (contd) ISOLATION – concurrent transactions DO NOT interfere with each other. Partial results of incomplete transactions are not visible to others before the transactions are committed. DURABILITY – transactions results are locked/ permanent after being committed. System guarantees that results of a committed transaction will be permanent even if a failure occurs after the commit. 5 © 2009 Georgia State University

  6. I:ACID (contd) DS Transaction: has a coordinator (initiates transaction and oversees activities) and participating processes (participants=remaining processes). EXAMPLE to follow 6 © 2009 Georgia State University

  7. I:ACID (contd) Example of commit time: Each coordinator and participant has access to stable storage. Either all nodes commit or none commit. The effects of the transaction are not visible until all nodes make a final decision to commit or abort (no rollback at this point). Activity Log captures history. 7 © 2009 Georgia State University

  8. I:TWO-PHASE COMMIT PROTOCOL [M. Duckett, 1995] 2PC assures that ACID properties are achieved! Previous example: * Responses are logged and the list is sent to each participant @ the time of the request message. 8 1st Phase 2nd Phase © 2009 Georgia State University

  9. I:2PC Failures and recovery actions. Continuing previous example (high level breakdown): 9 © 2009 Georgia State University

  10. II:CURRENT RESEARCH X/Open XA [IBM, Wiki, 2009]: What is it? Standard specification for distributed transaction processing (DTP). Provides interface between the global transaction manager and the local resource manager. 10 © 2009 Georgia State University

  11. II:X/OPENXA (contd) 11 PROBLEM:we can access multiple resources, but with multiple transactions there’s a lot of overhead [IBM, 2009]. • XA allows multiple resources (databases, app servers, etc.) to be accessed within the same transaction. • Preserves ACID properties across applications. • Uses 2PC implementation to ensure that all resources either commit, or rollback, any particular transaction simultaneously. © 2009 Georgia State University

  12. II:X/OPENXA(contd) RECEPTION? Supported by many vendors: MySQL support via the InnoDB storage engine and Oracle supported. Enterprise support and scalable technology. Clean Technology: benefits from the Open Source Community. Maybe built-in support can be rolled out with Linux or similar distros. 12 © 2009 Georgia State University

  13. II:X/OPENXA(contd) 13 Business Intelligence [IBM, 2009]: points to a balanced configuration unit (BCU). • In other words, DATA WAREHOUSING solutions are geared towards replicable and sustainable hardware + software means. • Multiple databases can be configured to a single unit of work (*ACID uptime is maintained.) © 2009 Georgia State University

  14. III:FUTURE POTENTIAL How can we take something that works well and MAKE it BETTER? 14 © 2009 Georgia State University

  15. III:PROPOSAL 15 SALES PITCH? • Does any product sell itself? No! There’s heavy marketing, promoting, and partnering involved. • Open XA caters to Data Warehousing with tight hardware coupling [IBM, Wiki, 2009]. • While initial benefits start at the basics: • Fewer transactions • Lower costs • Hardware costs have decreased, but depending on the specifics of a system, server & hardware costs can run high!!! © 2009 Georgia State University

  16. III:VIRTUALIZATION 16 PROS • Provides abstraction of resources. • User can forgo hardware specifics and it’s cheaper. • Multiple virtualization modes can be used based on the nature of the transaction. • Para, Partial, Full • If a virtualization machine (VM) instances goes down, it can easily be moved to a new host machine. CONS • Can NOT remove all traces of hardware either for a DW. • Security and authority concerns. • Performance differences for large tasks. • There’s no central Authority for Open Source lead efforts. • IT support trickles in late. • Implementation and security concerns. © 2009 Georgia State University

  17. REFERENCES [1] “Distributed Operating Systems & Algorithms”, Randy Chow and Theodore Johnson, 1997. [2] “Securing Applications using Operating System Transactions”, Erez Zadok, http://cip.cs.stonybrook.edu/ workshop/slides/3-zadok.pdf, 7-14-2006. [3] “Operating System Transactions”, Donald E. Porter, Owen S. Hofmann, Christopher J. Rossbach, Alexander Benn, and Emmett Witchel, 22nd ACM Symposium on Operating Systems Principles, October 2009. [4] “The Two-Phase Commit Protocol”, Mike Duckett, http://ei.cs.vt.edu/~cs5204/ sp99/distributedDBMS/duckett/tpcp.html, 4-30-1995. [5] “DB2 Universal Database”, IBM, http://publib.boulder.ibm.com/ infocenter/db2luw/v8/ index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0004558.htm, 4-30-2009. [6] “X/Open XA”, http://en.wikipedia.org/wiki/X/Open_XA, 8-9-2009. [7] “X/Open XA Standard”, http://www.opengroup.org/onlinepubs/009680699/toc.pdf, 1991. 17 © 2009 Georgia State University

  18. Q&A 18 © 2009 Georgia State University

More Related