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

2. O UTLINE  P ART I : I NTRODUCTION o Fundamentals o ACID Properties [ R. Chow & T. Johnson, 1997 ] o Two-phase Commit Protocol [M. Duckett, 1995]  P ART II : C URRENT R ESEARCH o X/Open XA [IBM, Wikipedia, 2009] o Distributed Relational Database Architecture (DRDA)  P ART III : F UTURE P OTENTIAL o Open XA Virtualization  R EFERENCES  Q & A 2 © 2009 Georgia State University

3. I : I NTRODUCTION [R. Chow & T. Johnson, 1997]  What is a Transaction? o The basic unit of client-server process interaction in a database (dbase) system, but it is NOT limited to it (ex: i t can also be used in a peer-to-peer protocol). o 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 : A CID [ R. Chow & T. Johnson, 1997]  A TOMICITY – ALL or NO operations in a transaction are performed. o Transaction Recovery System – ensures atomicity and enables the all or nothing output.  C ONSISTENCY – consistent state is maintained before a transaction starts and after it concludes. o Interleaved transactions  serial execution. 4 © 2009 Georgia State University

5. I : A CID (contd)  I SOLATION – concurrent transactions DO NOT interfere with each other. o Partial results of incomplete transactions are not visible to others before the transactions are committed.  D URABILITY – transactions results are locked/ permanent after being committed. o 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 : A CID (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 : A CID (contd)  Example of commit time: o Each coordinator and participant has access to stable storage. o Either all nodes commit or none commit. o The effects of the transaction are not visible until all nodes make a final decision to commit or abort (no rollback at this point). o Activity Log captures history. 7 © 2009 Georgia State University Storage Access AtomicityIsolation Activity Logged

8. I : T WO-PHASE C OMMIT P ROTOCOL [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 © 2009 Georgia State University COORDINATOR precommit the transaction Send request to all participants request PARTICIPANT received request message If (ready) precommit and send YES Else ABORT  send NO reply COORDINATOR collect all replies COORDINATOR If (all votes are unanimous) Commit & send COMMIT Else ABORT & send ABORT decision PARTICIPANT receive decision If (COMMIT)  commit If (ABORT)  abort send response result COORDINATOR received response 1 st Phase 2 nd Phase

9. I : 2PC  Failures and recovery actions.  Continuing previous example (high level breakdown): 9 © 2009 Georgia State University Failures before precommit(s) Abort transaction Equiv to send NO Failures after precommits but prior to commit Abort transaction Re-multicast request message Failures after a commit Resend commit message

10. II : C URRENT R ESEARCH 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 / O PEN XA (contd) 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. o Preserves ACID properties across applications. o Uses 2PC implementation to ensure that all resources either commit, or rollback, any particular transaction simultaneously. 11 © 2009 Georgia State University

12. II : X / O PEN XA (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. o Maybe built-in support can be rolled out with Linux or similar distros. 12 © 2009 Georgia State University

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

14. III : F UTURE P OTENTIAL How can we take something that works well and MAKE it BETTER? 14 © 2009 Georgia State University

15. III : P ROPOSAL 15 © 2009 Georgia State University 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: o Fewer transactions o Lower costs  Hardware costs have decreased, but depending on the specifics of a system, server & hardware costs can run high!!!

16. III : V IRTUALIZATION 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. o 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. 16 © 2009 Georgia State University

17. R EFERENCES [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&AQ&AQ&AQ&A 18 © 2009 Georgia State University