Your SlideShare is downloading. ×
0
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Svetlin Nakov - Database Transactions
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Svetlin Nakov - Database Transactions

4,202

Published on

Published in: Technology, Real Estate
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,202
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
329
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Transcript

    • 1. Database Transactions and Transaction Management Svetlin Nakov National Academy for Software Development academy.devbg.org
    • 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. 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. What is a Transaction?
    • 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. A Transaction Rollback Commit Read Write Write Durable starting state Durable, consistent, ending state Collection of reads and writes
    • 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. 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. 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. ACID Transactions
    • 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. 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. 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. 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. 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. 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. Concurrency Problems
    • 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. 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. 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. 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. 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. 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. 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. Concurrency Control Techniques
    • 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. 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. 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. 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. Locking Strategies
    • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Transactions and Recovery
    • 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. 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. 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. 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. Sample REDO Log File
    • 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. Transactions and SQL Language
    • 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. 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. 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. Transaction Isolation Levels
    • 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. 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. 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. When and How to Use Transactions?
    • 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. 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. Database Transactions and Transaction Management Questions ?

    ×