Transaction Processing

1. Transaction Processing Kittiphan Techakittiroj engktc@au.ac.th

2. Agenda • Introduction to Transaction and ACID • Transacion Models • TP Monitors • TP-lite & TP-heavy

3. Transaction Processing • Set of commands to process at once • Faster processing • Reduce the complexity of works • Easy example: saving a file not a character

4. Transaction Processing cont. • Big organization: do many things for one operation, e.g.check # of employee, assigned the salary, calculate the tax and make a payment • Banking is one example: check clearing

5. ACID Properties of Transaction • Atomicity: all operations as one item … either success all or fail all • Consistency: • correct, accurate, and valid • if the transaction is not success, server return to stable state • Isolation: not disturb with other transaction • Durability: after commit, the changes should be permanent (not effect by any failure)

6. Transaction Models • Describe the way a transaction can be processed • Should be general enough for any kinds of tranasaction • Make transactions accomplish the ACID properties

7. Transaction Models Models • Flat Transaction • Baby Stepping With Flat Transactions • Distributed Flat Transaction • Chained Transactions • Nested Transactions

8. Transaction Models: Models Flat Transaction • Contain three steps: • Begin Transaction • Process Transaction • End Transaction • Success: commit • Failure: abort + rollback

9. Transaction Models: Models: Flat Transaction Flat Transaction Providing ACID ACID • Atomicity • Consistency • Isolation • Durability Flat Transaction • Contain three steps: • Begin Transaction • Process Transaction • End Transaction • Success: commit • Failure: abort + rollback

10. Transaction Models: Models: Flat Transaction Baby Stepping with Flat Transaction • Eliminate the problems of Flat Transaction: • holding resource for too long • if abort, the whole works are gone • Separate the transaction to be small transactions

11. Transaction Models: Models: Flat Transaction Distributed Flat Transaction • Extend the Flat Transaction to multiple-site systems • Need the synchronization between each site

12. Transaction Models: Models: Flat Transaction: Distributed Flat Transaction Two Phase Commit Protocol • synchronization for Distributed Flat Transaction • Consider two types of systems • commit manager node or root node or transaction coordinator • subordinate nodes • Two main phases: • Ask everyone to be ready to commit • Ask every one to commit

13. Transaction Models: Models: Flat Transaction: Distributed Flat Transaction Two Phase Commit Protocol cont. • First Phase • commit manager sends “prepare-to-commit” • commit manager wait for “ready-to-commit” • first phase finish when all nodes is “ready-to-commit”

14. Transaction Models: Models: Flat Transaction: Distributed Flat Transaction Two Phase Commit Protocol cont. • Second Phase • commit manager send “commit” • commit ended: • all nodes complete “commit” • negative response from any node make commit manager order “rollback” to every nodes

15. Transaction Models: Models: Flat Transaction Limitations • transactions that need to be partially rooled back • transactions with humans in the loop: causes the hold of resources for long period (something might also happens on the way, e.g. GUI cracked)

16. Transaction Models: Models: Flat Transaction Limitations cont. • transaction with long time update • large transaction: e.g. updates of million records • transaction across companies or the Internet: political and privacy issues

17. Transaction Models: Models: Chained Transaction • chaining many transaction together • three common patterns: • syncpoints • chained transactions • sagas

18. Transaction Models: Models: Chained Transaction Syncpoints • Make synchronization points in-between transaction • Allow the rollback at each synchronization point • not durable to the system crash

19. Transaction Models: Models: Chained Transaction Chained Transaction • make the synchronization points become “commit” • create “durability” • lost “atomic”: the ability to roll-back entired transaction

20. Transaction Models: Models: Chained Transaction Sagas • same as normal chained transactions but allow the roll-back for the entire transaction • this create the “atomic” • need to keep track the entired process of transaction

21. Transaction Models: Models: Nested Transaction • allow transactions inside a transaction • hierarchies of “subtransactions”

22. TP Monitors • process management: start server process, monitor process • transaction management: queuing, transaction scheduling, prioritization service • communications management between clients and the server

23. TP Monitors cont.

24. TP Monitor Funneling • the management over OS • two mains functions • pass the client request to server • load balancing

25. TP Monitor: Funneling Main Functions • load balancing: • create process if necessary • destroy process if possible • however create or destroy processes to often cause the slow down of the systems

26. TP Monitor Benefits • Client/Server application development framework: TP monitor as middleware • Firewalls of protection • High availability • Load balancing • Scalability of function • Reduced system cost

27. TP-lite & TP-heavy • TP-Lite is the concept of embedding TP Monitor into the DBMS • TP-Heavy is the way to put TP Monitor as a separate item

28. TP-lite & TP-heavy Scope of “commit • Limit by the way the TP monitor is built • When nested transaction • TP-Lite is limited because mostly DBMS call nested transaction separately

29. TP-lite & TP-heavy Performance • TP-Heavy reduce the load of server

30. Reference Books Client/server survival guide 3rd edition by Robert Orfali, Dan Harkey, Jeri Edwards (John Wiley & Sons: 1999) Client Server Computing: A Management Overview by Patrick Martin (http://www.natlearn.com.au/cliserco.htm: November1998) Clinet/Server Applications (http://doro.srv.gc.ca/gena/ai/client_e.html: July 1997)

31. Reference Books Scale Up with TP Monitors by Jim Gray and Jeri Edwards (Byte Magazine: April 1995) Next-Generation TP Monitors by Nick Gall (http://www.nwc.com/816/816colgall.html: August 1999)