Svetlin Nakov - Database Transactions


Published on

Published in: Technology, Real Estate
  • Be the first to comment

Svetlin Nakov - Database Transactions

  1. 1. Database Transactions and Transaction Management Svetlin Nakov National Academy for Software Development
  2. 2. Agenda <ul><li>What is a Transaction? </li></ul><ul><li>ACID Transactions </li></ul><ul><li>Concurrency Problems </li></ul><ul><li>Concurrency Control Techniques </li></ul><ul><li>Locking Strategies </li></ul><ul><ul><li>Optimistic vs. Pessimistic Locking </li></ul></ul><ul><ul><li>Deadlocks </li></ul></ul><ul><li>Transactions and Recovery </li></ul>
  3. 3. Agenda (2) <ul><li>Transactions and SQL Language </li></ul><ul><li>Transaction Isolation Levels </li></ul><ul><li>When and How to Use Transactions? </li></ul>
  4. 4. What is a Transaction?
  5. 5. Transactions <ul><li>Transactions are a sequence of actions ( database operations ) which are executed as a whole : </li></ul><ul><ul><li>Either all of them execute successfully </li></ul></ul><ul><ul><li>Or none of the them </li></ul></ul><ul><li>Example : </li></ul><ul><ul><li>A bank transfer from one account into another ( withdrawal + deposit ) </li></ul></ul><ul><ul><li>If either the withdrawal or the deposit fails the whole operation is cancelled </li></ul></ul>
  6. 6. A Transaction Rollback Commit Read Write Write Durable starting state Durable, consistent, ending state Collection of reads and writes
  7. 7. Transactions Behavior <ul><li>Transactions guarantee the consistency and the integrity of the database </li></ul><ul><ul><li>All changes in a transaction are temporary </li></ul></ul><ul><ul><li>Changes become final when COMMIT is executed </li></ul></ul><ul><ul><li>At any time all changes can be canceled by ROLLBACK </li></ul></ul><ul><li>All of the operations are executed as a whole, either all of them or none of them </li></ul>
  8. 8. Transactions: Examples <ul><li>Withdraw $100 </li></ul><ul><li>Read savings </li></ul><ul><li>New savings = current - 100 </li></ul><ul><li>Read checking </li></ul><ul><li>New checking = current + 100 </li></ul><ul><li>Write savings </li></ul><ul><li>Write checking </li></ul><ul><li>Read current balance </li></ul><ul><li>New balance = current - 100 </li></ul><ul><li>Write new balance </li></ul><ul><li>Dispense cash </li></ul>Transfer $100
  9. 9. What Can Go Wrong? <ul><li>Some actions fail to complete </li></ul><ul><ul><li>For example, the application software or database server crashes </li></ul></ul><ul><li>Interference from another transaction </li></ul><ul><ul><li>What will happen if several transfers run for the same account in the same time? </li></ul></ul><ul><li>Some data lost after actions complete </li></ul><ul><ul><li>Database crashes after withdraw is complete and all other actions are lost </li></ul></ul>
  10. 10. ACID Transactions
  11. 11. Transactions Properties <ul><li>DBMS servers have built-in transaction support </li></ul><ul><ul><li>Contemporary databases implement “ACID” transactions </li></ul></ul><ul><li>ACID means: </li></ul><ul><ul><li>A tomicity </li></ul></ul><ul><ul><li>C onsistency </li></ul></ul><ul><ul><li>I solation </li></ul></ul><ul><ul><li>D urability </li></ul></ul>
  12. 12. Atomicity <ul><li>Atomicity means that </li></ul><ul><ul><li>Transactions execute as a whole </li></ul></ul><ul><ul><li>DBMS to guarantee that either all of the tasks of a transaction are performed or none of them are </li></ul></ul><ul><li>Atomicity example: </li></ul><ul><ul><li>Transfer funds between bank accounts </li></ul></ul><ul><ul><ul><li>Either withdraw and deposit both execute successfully or none of them </li></ul></ul></ul><ul><ul><ul><li>In case of failure DB stays unchanged </li></ul></ul></ul>
  13. 13. Consistency <ul><li>Consistency means that </li></ul><ul><ul><li>The database is in a legal state when the transaction begins and when it ends </li></ul></ul><ul><ul><li>O nly valid data will be written to the database </li></ul></ul><ul><ul><li>Transaction cannot break the rules of the database, e.g. integrity constraints </li></ul></ul><ul><ul><ul><li>Primary, foreign, alternate keys </li></ul></ul></ul><ul><li>Consistency example </li></ul><ul><ul><li>Transaction cannot end with a duplicate primary key in a table </li></ul></ul>
  14. 14. Isolation <ul><li>Isolation means that </li></ul><ul><ul><li>Multiple transactions running at the same time not impact each other’s execution </li></ul></ul><ul><ul><li>Transactions don’t see other transaction’s uncommitted changes </li></ul></ul><ul><ul><li>Isolation level defines how deep transactions isolate from one another </li></ul></ul><ul><ul><ul><li>Read committed, read uncommitted, repeatable read, serializable, etc. </li></ul></ul></ul><ul><li>Isolation example: </li></ul><ul><ul><li>Manager can see the transferred funds on one account or the other, but never on both </li></ul></ul>
  15. 15. Durability <ul><li>Durability means that </li></ul><ul><ul><li>If a transaction is confirmed it become persistent </li></ul></ul><ul><ul><ul><li>Cannot be lost or undone </li></ul></ul></ul><ul><ul><li>E nsured through the use of database backups and transaction logs </li></ul></ul><ul><li>Durability example: </li></ul><ul><ul><li>After transfer funds and commit the power supply is lost </li></ul></ul><ul><ul><li>Transaction stays persistent </li></ul></ul>
  16. 16. ACID Transactions and RDBMS Servers <ul><li>Popular RDBMS servers are transactional : </li></ul><ul><ul><li>Oracle Database </li></ul></ul><ul><ul><li>Microsoft SQL Server </li></ul></ul><ul><ul><li>IBM DB2 </li></ul></ul><ul><ul><li>PostgreSQL </li></ul></ul><ul><ul><li>Borland InterBase / Firebird </li></ul></ul><ul><li>All of the above servers support ACID transactions </li></ul><ul><ul><li>MySQL can also run in ACID mode </li></ul></ul>
  17. 17. Concurrency Problems
  18. 18. Scheduling Transactions <ul><li>Serial schedule – the ideal case </li></ul><ul><ul><li>An ordering of operations of the transactions so with no interleaving </li></ul></ul><ul><ul><li>Problem: Doesn’t allow for as much concurrency as we’d like </li></ul></ul><ul><li>Conflicting operations </li></ul><ul><ul><li>Two operations conflict if they </li></ul></ul><ul><ul><ul><li>1) are from different transactions </li></ul></ul></ul><ul><ul><ul><li>2) access the same item, and </li></ul></ul></ul><ul><ul><ul><li>3) at least one of the transactions does a write operation to that item </li></ul></ul></ul>
  19. 19. Serial Schedule – Example <ul><li>T1: Adds 50 to the balance </li></ul><ul><li>T2: Subtracts 25 from the balance </li></ul><ul><li>T1 completes before T2 begins: no concurrency problems </li></ul>Time Trans. Step Value 6 T 2 Write balance 125 5 T 2 4 T 2 Read balance 150 3 T 1 Write balance 150 2 T 1 balance = 100 + 50 1 T 1 Read balance 100 balance = 150 - 25
  20. 20. Serializable Transactions <ul><li>Serializability </li></ul><ul><ul><li>Want to get the effect of serial schedules, but allow for more concurrency </li></ul></ul><ul><ul><li>Serializable schedules </li></ul></ul><ul><ul><ul><li>Equivalent to serial schedules </li></ul></ul></ul><ul><ul><ul><li>Produce same final result as serial schedule </li></ul></ul></ul><ul><li>Locking mechanisms can ensure serializability </li></ul><ul><li>Serializability is too expensive </li></ul><ul><ul><li>Optimistic locking allows better concurrency </li></ul></ul>
  21. 21. Concurrency Problems <ul><li>Problems from conflicting operations: </li></ul><ul><ul><li>Dirty Read (Temporary Update) </li></ul></ul><ul><ul><ul><li>A transaction updates an item, then fails </li></ul></ul></ul><ul><ul><ul><li>The item is accessed by another transaction before rollback </li></ul></ul></ul><ul><ul><li>Non-Repeatable Read </li></ul></ul><ul><ul><ul><li>A transactions reads an item twice and gets different values because of concurrent change </li></ul></ul></ul><ul><ul><li>Phantom Read </li></ul></ul><ul><ul><ul><li>A transaction executes a query twice, and obtains a different numbers of rows because a nother transaction inserted new rows meantime </li></ul></ul></ul>
  22. 22. Concurrency Problems (2) <ul><li>Problems from conflicting operations: </li></ul><ul><ul><li>Lost Update </li></ul></ul><ul><ul><ul><li>Two transactions update the same item </li></ul></ul></ul><ul><ul><ul><li>Second update overwrites the first (last wins) </li></ul></ul></ul><ul><ul><li>Incorrect Summary </li></ul></ul><ul><ul><ul><li>One transaction is calculating an aggregate function on some records while another transaction is updating them </li></ul></ul></ul><ul><ul><ul><li>The aggregate function calculate some values before updating and some after </li></ul></ul></ul>
  23. 23. Dirty Read (Read Uncommitted) – Example T2 writes incorrect balance <ul><li>Update from T1 was rolled back, but T2 doesn’t know about it, so finally the balance is incorrect. </li></ul>Time Trans. Step Value 6 T 1 Rollback 125 5 T 2 4 T 2 Read balance 3 T 1 2 T 1 1 T 1 Read balance 100 balance = 150 - 25 150 balance = 100 + 50 Write balance 1 5 0 7 T 2 Write balance Uncommitted Undoes T1
  24. 24. Lost Update – Example Lost update!! <ul><li>Update from T1 is lost because T2 reads balance before T1 was complete </li></ul>Time Trans. Step Value 6 T 2 Write balance 7 5 5 T 1 4 T 2 balance = balance - 25 3 T 1 balance = balance + 50 2 T 2 Read balance 1 T 1 Read balance 100 Write balance 100 150
  25. 25. Concurrency Control Techniques
  26. 26. Concurrency Control <ul><li>The problem </li></ul><ul><ul><li>Conflicting operations in simultaneous transactions may produce an incorrect results </li></ul></ul><ul><li>What is concurrency control? </li></ul><ul><ul><li>Managing simultaneous operations on the database without having them interfere with one another </li></ul></ul><ul><ul><li>Prevents conflicts when two or more users access database simultaneously </li></ul></ul>
  27. 27. Concurrency Control Techniques <ul><li>Two basic concurrency control techniques: </li></ul><ul><ul><li>Locking </li></ul></ul><ul><ul><ul><li>Used in most RDBMS servers, e.g. Oracle, SQL Server, etc. </li></ul></ul></ul><ul><ul><li>Timestamping </li></ul></ul><ul><li>Both are conservative (pessimistic) approaches: delay transactions in case they conflict with other transactions </li></ul><ul><li>Optimistic methods assume conflict is rare and only check for conflicts at commit </li></ul>
  28. 28. Locking <ul><li>Transaction uses locks to deny access to shared data by the other transactions </li></ul><ul><ul><li>Most widely used approach to ensure serializability </li></ul></ul><ul><ul><li>Generally, a transaction must claim a read (shared) or write (exclusive) lock on a data item before read or write </li></ul></ul><ul><ul><li>Lock prevents another transaction from modifying item or even reading it, in the case of a write lock </li></ul></ul><ul><ul><li>Deadlock is possible </li></ul></ul>
  29. 29. Timestamping <ul><li>A unique identifier </li></ul><ul><ul><li>Created by the DBMS </li></ul></ul><ul><ul><li>Indicates relative starting time of a transaction </li></ul></ul><ul><li>Transactions ordered globally </li></ul><ul><ul><li>Older transactions (earlier timestamps) get priority in the event of conflict </li></ul></ul><ul><li>Conflict is resolved by rolling back and restarting transaction </li></ul><ul><li>No locks so no deadlock </li></ul>
  30. 30. Locking Strategies
  31. 31. Locking Strategies <ul><li>Optimistic locking </li></ul><ul><ul><li>Locks are not used </li></ul></ul><ul><ul><li>Conflicts are possible but are resolved before commit </li></ul></ul><ul><ul><li>High concurrency – scale well </li></ul></ul><ul><li>Pessimistic locking </li></ul><ul><ul><li>Use exclusive and shared locks </li></ul></ul><ul><ul><li>Transactions wait for each other </li></ul></ul><ul><ul><li>Low concurrency – does not scale </li></ul></ul>
  32. 32. Optimistic Locking <ul><li>Optimistic locking means no locking </li></ul><ul><li>Based on assumption that conflicts are rare </li></ul><ul><li>It is more efficient to let transactions proceed without delays to ensure serializability </li></ul><ul><li>At commit, check is made to determine whether conflict has occurred </li></ul><ul><li>If there is a conflict, transaction must be rolled back and restarted </li></ul><ul><li>Allows greater concurrency than pessimistic locking </li></ul>
  33. 33. Optimistic Locking Phases <ul><li>Three phases </li></ul><ul><ul><li>Read </li></ul></ul><ul><ul><ul><li>Transaction reads the DB, does computations, then makes updates to a private copy of the DB (e.g. in the memory) </li></ul></ul></ul><ul><ul><li>Validation </li></ul></ul><ul><ul><ul><li>Make sure that transaction doesn’t cause any integrity/consistency problems </li></ul></ul></ul><ul><ul><ul><li>If no problems, transaction goes to write phase </li></ul></ul></ul><ul><ul><ul><li>If problems, changes are discarded and transaction is restarted </li></ul></ul></ul><ul><ul><li>Write </li></ul></ul><ul><ul><ul><li>Changes are made persistent to DB </li></ul></ul></ul>
  34. 34. Pessimistic Locking <ul><li>A ssume conflicts are likely </li></ul><ul><ul><li>Lock shared data to avoid conflicts </li></ul></ul><ul><ul><li>Transactions wait each other – does not scale well </li></ul></ul><ul><li>Use shared and exclusive locks </li></ul><ul><ul><li>Transactions must claim a read (shared) or write (exclusive) lock on a data item before read or write </li></ul></ul><ul><ul><li>Locks prevents another transaction from modifying item or even reading it, in the case of a write lock </li></ul></ul>
  35. 35. Locking – Basic Rules <ul><li>If transaction has read lock on an item, the item can be read but not modified </li></ul><ul><li>If transaction has write lock on an item, the item can be both read and modified </li></ul><ul><li>Reads cannot conflict, so multiple transactions can hold read locks simultaneously on the same item </li></ul><ul><li>Write lock gives one transaction exclusive access to an item </li></ul><ul><li>Transaction can upgrade a read lock to a write lock, or downgrade a write lock to a read lock </li></ul><ul><li>Commits or rollbacks release the locks </li></ul>
  36. 36. Deadlock <ul><li>What is deadlock? </li></ul><ul><ul><li>When two (or more) transactions are each waiting for locks held by the other to be released </li></ul></ul><ul><li>Breaking a deadlock </li></ul><ul><ul><li>Only one way to break deadlock: abort one or more of the transactions </li></ul></ul>
  37. 37. Dealing with Deadlock <ul><li>Deadlock prevention </li></ul><ul><ul><li>Transaction can’t obtain a new lock if the possibility of a deadlock exists </li></ul></ul><ul><li>Deadlock avoidance </li></ul><ul><ul><li>Transaction must obtain all the locks it needs before it starts </li></ul></ul><ul><li>Deadlock detection and recovery </li></ul><ul><ul><li>DB checks for possible deadlocks </li></ul></ul><ul><ul><li>If deadlock is detected, one of the transactions is killed, then restarted </li></ul></ul>
  38. 38. Lock Management <ul><li>Lock and unlock requests are handled by the lock manager, stored in the “lock table” </li></ul><ul><li>Lock table entries store: </li></ul><ul><ul><li>Number of transactions currently holding a lock </li></ul></ul><ul><ul><li>Type of lock held (shared or exclusive) </li></ul></ul><ul><ul><li>Pointer to queue of lock requests </li></ul></ul><ul><li>Locking and unlocking have to be atomic operations </li></ul><ul><li>Lock upgrade: transaction that holds a shared lock can be upgraded to exclusive lock </li></ul>
  39. 39. Locking Granularity <ul><li>Size of data items chosen as unit of protection by concurrency control </li></ul><ul><li>Ranging from coarse to fine: </li></ul><ul><ul><li>Entire database </li></ul></ul><ul><ul><li>File </li></ul></ul><ul><ul><li>Page (block) </li></ul></ul><ul><ul><li>Record </li></ul></ul><ul><ul><li>Field value of a record </li></ul></ul>
  40. 40. Coarse vs. Fine Granularity <ul><li>G ranularity is a measure of the amount of data the lock is protecting </li></ul><ul><li>Coarse granularity </li></ul><ul><ul><li>Small number of locks protecting large segments of data, e.g. DB, file, page locks </li></ul></ul><ul><ul><li>Small overhead, small concurrency </li></ul></ul><ul><li>Fine granularity </li></ul><ul><ul><li>Large number of locks over small areas of data, e.g. table row of field in a row </li></ul></ul><ul><ul><li>More overhead, more concurrency </li></ul></ul><ul><li>DBMS servers are “smart” and use both </li></ul>
  41. 41. Transactions and Recovery
  42. 42. Transactions and Recovery <ul><li>Transactions represent basic unit of recovery </li></ul><ul><li>Recovery manager responsible for atomicity and durability </li></ul><ul><li>What happens at failure? </li></ul><ul><ul><li>If transaction had not committed at failure time, recovery manager has to undo ( rollback ) any effects of that transaction for atomicity </li></ul></ul><ul><ul><li>If failure occurs between commit and database buffers being flushed to secondary storage, recovery manager has to redo ( rollforward ) transaction's updates </li></ul></ul>
  43. 43. Crash Before Completion – Sample Scenario <ul><li>Application tries to transfer $100 </li></ul><ul><ul><li>Read savings </li></ul></ul><ul><ul><ul><li>new savings = current - 100 </li></ul></ul></ul><ul><ul><li>Read checking </li></ul></ul><ul><ul><ul><li>new checking = current + 100 </li></ul></ul></ul><ul><ul><li>Write savings to DB </li></ul></ul><ul><ul><li>System crash before write of new checking balance </li></ul></ul>
  44. 44. Recovery from Crash <ul><li>Rollback </li></ul><ul><ul><li>Recover to the starting state: </li></ul></ul><ul><ul><ul><li>Take snapshot (checkpoint) of starting state </li></ul></ul></ul><ul><ul><ul><ul><li>E.g., initial bank balance (and all other states) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>And keep a “redo” log </li></ul></ul></ul></ul><ul><ul><ul><li>Alternative: keep an “undo” log </li></ul></ul></ul><ul><ul><ul><ul><li>E.g., bank balance changed: old value was x </li></ul></ul></ul></ul><ul><li>Resume (if recoverable) </li></ul><ul><ul><li>Redo all committed actions (since last checkpoint) </li></ul></ul><ul><ul><li>Or undo all uncommitted actions </li></ul></ul>
  45. 45. Creating REDO Log <ul><li>Keep a log of all database writes ON DISK (so that it is still available after crash) </li></ul><ul><ul><li><transaction ID>; <data item>; <new value> </li></ul></ul><ul><ul><ul><li>(Tj; x=125) (Ti; y=56) </li></ul></ul></ul><ul><ul><ul><li>Actions must be idempotent (redoable) </li></ul></ul></ul><ul><ul><ul><ul><li>NOT x = x + 100 </li></ul></ul></ul></ul><ul><ul><li>But don't write to the database yet </li></ul></ul><ul><li>At the end of transaction execution </li></ul><ul><ul><li>Add &quot;commit <transaction ID>&quot; to the log </li></ul></ul><ul><ul><li>Do all the writes to the database </li></ul></ul><ul><ul><li>Add &quot;complete <transaction ID>&quot; to the log </li></ul></ul>
  46. 46. Sample REDO Log File
  47. 47. Recovering From a Crash <ul><li>There are 3 phases in the recovery algorithm: </li></ul><ul><ul><li>Analysis – scan the log forward to identify all transactions that were active, and all dirty pages in the buffer pool at the time of the crash </li></ul></ul><ul><ul><li>Redo – redoes all updates to dirty pages in the buffer pool, as needed, to ensure that all logged updates are in fact carried out and written to disk </li></ul></ul><ul><ul><li>Undo – all transactions that were active at the crash are undone, working backwards in the log </li></ul></ul><ul><li>Some care must be taken to handle the case of a crash occurring during the recovery process! </li></ul>
  48. 48. Transactions and SQL Language
  49. 49. Transactions and SQL <ul><li>Start a transaction </li></ul><ul><ul><li>BEGIN TRANSACTION </li></ul></ul><ul><ul><li>Some databases assume implicit start </li></ul></ul><ul><ul><ul><li>E.g. Oracle </li></ul></ul></ul><ul><li>Ending a transaction </li></ul><ul><ul><li>COMMIT </li></ul></ul><ul><ul><ul><li>Used to end a successful transaction and make changes “permanent” </li></ul></ul></ul><ul><ul><li>ROLLBACK </li></ul></ul><ul><ul><ul><li>“ Undo” changes from an aborted transaction </li></ul></ul></ul><ul><ul><ul><li>May be done automatically when failure occurs </li></ul></ul></ul>
  50. 50. Transactions in SQL Server: Example <ul><li>We have a table with bank accounts : </li></ul><ul><li>We use a transaction to transfer money from one account into another </li></ul>CREATE TABLE ACCOUNT ( id int NOT NULL, balance decimal NOT NULL) CREATE OR REPLACE PROCEDURE sp_Transfer_Funds( from_account IN INT, to_account IN INT, ammount IN NUMBER ) IS BEGIN BEGIN TRAN ( example continues )
  51. 51. Transactions in SQL Server: Example (2) UPDATE ACCOUNT set balance = balance - ammount WHERE id = from_account; IF SQL%ROWCOUNT <> 1 THEN ROLLBACK; RAISE_APPLICATION_ERROR(-20001, 'Invalid src account!'); END IF; UPDATE ACCOUNT set balance = balance + ammount WHERE id = to_account; IF SQL%ROWCOUNT <> 1 THEN ROLLBACK; RAISE_APPLICATION_ERROR(-20002, 'Invalid dst account!'); END IF; COMMIT; END;
  52. 52. Transaction Isolation Levels
  53. 53. Transactions and isolation <ul><li>Transactions can define different isolation levels for themselves </li></ul><ul><ul><li>Stronger isolation ensures better consistency but has less concurrency and the data is locked longer </li></ul></ul>yes no no Repeatable read yes yes no Read committed no yes Dirty reads no yes Repeatable reads no yes Phantom reads Serializable Read uncommitted Level of isolation
  54. 54. Isolation levels <ul><li>Uncommitted Read </li></ul><ul><ul><li>Reads everything, even data not committed by some other transaction </li></ul></ul><ul><ul><li>No data is locked </li></ul></ul><ul><ul><li>Not commonly used </li></ul></ul><ul><li>Read Committed </li></ul><ul><ul><li>Current transaction sees only committed data </li></ul></ul><ul><ul><li>Records retrieved by a query are not prevented from modification by some other transaction </li></ul></ul><ul><ul><li>Default behavior in most databases </li></ul></ul>
  55. 55. Isolation levels <ul><li>Repeatable Read </li></ul><ul><ul><li>Records retrieved cannot be changed from outside </li></ul></ul><ul><ul><li>The transaction acquires read locks on all retrieved data, but does not acquire range locks (phantom reads may occur) </li></ul></ul><ul><ul><li>Deadlocks can occur </li></ul></ul><ul><li>Serializable </li></ul><ul><ul><li>Acquires a range lock on the data </li></ul></ul><ul><ul><li>Simultaneous transactions are actually executed one after another </li></ul></ul>
  56. 56. When and How to Use Transactions?
  57. 57. Transactions Usage <ul><li>When force using transactions? </li></ul><ul><ul><li>Always when a business operation modifies more than one table (atomicity) </li></ul></ul><ul><ul><li>When you don’t want conflicting updates (isolation) </li></ul></ul><ul><li>How to choose isolation level? </li></ul><ul><ul><li>Use read committed, unless you need more strong isolation </li></ul></ul><ul><li>Keep transactions small in time </li></ul><ul><ul><li>Never keep transactions opened for long </li></ul></ul>
  58. 58. Transactions Usage – Examples <ul><li>Transfer money from one account to another </li></ul><ul><ul><li>Either both withdraw and deposit succeed or neither of them </li></ul></ul><ul><li>At the pay desk of a store : we buy a cart of products as a whole </li></ul><ul><ul><li>We either buy all of them and pay or we buy nothing and give no money </li></ul></ul><ul><ul><li>If any of the operations fails we cancel the transaction ( the entire purchase ) </li></ul></ul>
  59. 59. Database Transactions and Transaction Management Questions ?