1. PAVANI REDDY KATHURI TRANSACTION COMMUNICATION

2. OUTLINE 0 P ART I : I NTRODUCTION 0 P ART II : C URRENT R ESEARCH 0 P ART III : F UTURE P OTENTIAL 0 R EFERENCES

3. WHAT IS TRANSACTION? 0 Fundamental unit of interconnection b/w client and server processes in database system. In Transactions we have, Database Transaction Communication Transaction

4. ACID PROPERTIES 0 Atomicity 0 Consistency 0 Isolation 0 Durability

5. ATOMICITY 0 Either all the operations in a transaction are performed in its entirety or not performed at all. CONSISTENCY 0 consistent state is maintained before a transaction starts and after it concludes.

6. 0 ISOLATION A transaction should appear as it is being executed in isolation form other transactions. 0 DURABILITY Transactions results are locked/ permanent after being committed.

7. DISTRIBUTED TRANSACTION 0 One coordinator (usually the initiator of the transaction) and several participating processes (remote process) 0 At commit Atomicity: either all nodes commit or none do Isolation: effects of the transaction not made visible until all nodes have made an irrevocable decision to commit or abort

8. ACTIVITY LOG Each participant keeps track of updated data objects by maintaining a private work space. Updates contain old and new value. Each site has an activity log which is kept on the disk. 0 - On abort: undo of uncommitted transactions (rollback)‏ 0 - After crash: redo of committed transactions (roll forward)‏ Needed for durability of committed transactions

9. SHADOW PAGING Here, transaction logs are not required. Two directories created during the life of transaction - current directory - shadow directory When transaction starts, both directories are same. Shadow directory never changed during the transaction. Current directory updated when write operation is performed. When transaction commits, shadow directory is discarded and current directory is copied to the storage

10. TWO PHASE COMMIT PROTOCOL 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

11. 2PC COORDINATOR 1. Prepare to commit the transaction by writing every update in activity log. within the time-out period, multicast a commit message. Otherwise, multicast an abort message. 2. Write a precommit message in the activity log. Send a voting message to all participants asking whether they are ready to commit. 3. If all participants vote yes

12. PARTICIPANT 1. Prepare to commit the transaction by writing every update in activity log. 2. Write a precommit message in the activity log. Wait for request to vote from coordinator. 3. When receiving a vote request, test whether the transaction can be committed and if yes, writes a precommit to its activity log and sends a YES reply, otherwise send a NO reply. 4. Wait for commit message from the coordinator. If received, commit the transaction. If abort message is received, abort the transaction.

13. FAILURE AND RECOVERY ACTIONS 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

14. PARTICIPANT 1. Prepare to commit the transaction by writing every update in activity log. 2. Write a precommit message in the activity log. Wait for request to vote from coordinator. 3. When receiving a vote request, test whether the transaction can be committed and if yes, writes a precommit to its activity log and sends a YES reply, otherwise send a NO reply. 4. Wait for commit message from the coordinator. If received, commit the transaction. If abort message is received, abort the transaction.

15. RELATED LINK 0 http://en.wikipedia.org/wiki/Two-phase_commit_protocol http://en.wikipedia.org/wiki/Two-phase_commit_protocol

16. NESTED TRANSACTION Nested transaction = tree of transactions 0 Commit of a subtransaction takes place only if parent transaction commits 0 Rollback of a transaction forces rollback of all its subtransactions

17. RULES FOR NESTED TRANSACTIONS Commit rule 0 Commit of a transaction makes it result accessible only to its parent Rollback rule 0 If a transaction is rolled back, all its subtransactions are also rolled back (whatever their status)

18. RULES FOR NESTED TRANSACTION (CONT’D) Visibility rule 0 All changes by a subtransaction are visible to parent upon local commit. Locking rule 0 Externally, top-level transaction holds all locks 0 Internally, multiple transactions may hold exclusive locks

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

20. X / O PEN XA PROBLEM: we can access multiple resources, but with multiple transactions there’s a lot of overhead [IBM, 2009]. 0 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. 20 © 2009 Georgia State University

22. RELATED LINKS [1] “X/Open XA”, http://en.wikipedia.org/wiki/X/Open_XA, 8-9- 2009. [2] “X/Open XA Standard”, http://www.opengroup.org/onlinepubs/009680699/toc.pdf, 1991

23. FUTURE WORK

24. PROPOSAL 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!!!

25. PROS 0 Provides abstraction of resources. 0 User can forgo hardware specifics and it’s cheaper. 0 Multiple virtualization modes can be used based on the nature of the transaction. o Para, Partial, Full

26. 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.

27. REFERENCES [1] Distributed Operating Systems & Algorithms, by 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] Mohammad Alrifai etc., Transactions Concurrency Control in Web Service Environment,2000

28. THANK YOU