Your SlideShare is downloading. ×
3 transaction
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

3 transaction


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. 3. Acid Property of Transactions Transactions should possess several properties. These are often called the acid properties, and they should be enforced by the concurrency control and recovery methods of the DBMS. ♦ Acid properties: ▪ Atomicity: Transaction is an atomic unit of processing; Performed entirety or not. ▪ Consistency preservation: ▪ Isolation: Execution of a transaction should not be interfered with other transactions. ▪ Durability or permanency: The changes applied to the database by a committed transaction must persist in the database.
  • 2. 3. Acid Property of Transactions ▪ Atomicity: Consider the case of funds transfer from account a to account b. A.bal -= amount; B.bal += amount; A.bal -= amount; Crash … … Recovery A.bal += amount;  rollback Within the scope of a transaction - all changes occur together or no changes occur - atomicity is the responsibility of the transaction manager Ex) a money transfer, debit removes funds, credit add funds, no funds are lost!
  • 3. 3. Acid Property of Transactions ▪ Consistency preservation: • Consider the case of funds transfer from account a to account b. A.bal -= amount; B.bal += amount; A.bal -= amount; B.bal += amount(fails!! A’s balance is 0) A.bal += amount;  rollback • Transactions scope a set of operations - consistency can be violated within a transaction - transaction must be correct according to application rules - begin and commit are points of consistency - consistency preservation is a property of a transaction, not of the tp system.
  • 4. 3. Acid Property of Transactions ▪ Isolation : • Consider the case of funds transfer from account a to account b. Transaction t1: A.bal -= amount; (let a’s balance become 0 after this…) B.bal += amount; Transaction t2: A.bal -= amount2; Net effect should be either t1,t2 (in which case t2 fails) or t2,t1 (in which case t1 fails).
  • 5. 3. Acid Property of Transactions ▪ Durability : • Consider the case of funds transfer from account a to account b. Account a should have a balance of amount Transaction t1: A.bal -= amount; B.bal += amount; Commit Account a should have a balance of 0. • When a transaction commits, its results must survive failures – must be durably recorded prior to commit – system waits for disk ask before asking to user • If a transaction rolls back, changes must be undone – before images recorded – undo processing after failure
  • 6. 4. Transaction States ◆ Transaction States Active: initial state; when the transaction is executing Partially committed: when the last statement has finished execution Failed: on discovery that normal execution can no longer proceed Aborted: after the rollback is performed from a failed transaction Committed: after successful completion Terminated: either committed or aborted
  • 7. 4. Transaction States ◆ Transaction Execution A transaction reaches its commit point when all operations accessing the database are completed and the result has been recorded in the log. It then writes a [commit, transaction-id]. If a system failure occurs, searching the log and rollback the transactions that have written into the log a [start_transaction, transaction-id] [write_item, transaction-id, x, old_value, new_value] But have not recorded into the log a [commit, transaction-id]
  • 8. 4. Transaction States ◆ Transaction states and additional operations For recovery purposes, the system needs to keep track of when the transaction starts, terminates, and commits or aborts (see below). Hence, the recovery manager keeps track of the following operations: Begin transaction: End transaction: Commit transaction: Rollback (or abort):
  • 9. 4. Transaction States ◆ Acid using shadow copy • Assume that only one transaction is active at a time. • db pointer always points to the current consistent copy of the database. • All updates are made on a shadow copy of the database, and db pointer is made to point to the updated shadow copy only after the transaction reaches partial commit and all updated pages have been flushed to disk. • In case transaction fails, old consistent copy pointed to by db pointer can be used, and the shadow copy can be deleted. • Simple but extremely inefficient implementation • Assumes database to be a file.
  • 10. 4. Transaction States ◆ The shadow-database scheme This assumes disks do not fail. It is useful for text editors, but extremely inefficient for large databases and does not handle concurrent transactions.
  • 11. 4. Transaction States ◆ Transaction as a Concurrency Unit Transactions must be synchronized for database consistency.
  • 12. 4. Transaction States ◆ Concurrent executions Multiple transactions are allowed to run concurrently. Advantages are: Increased processor and disk utilization Reduced average response time for transactions Concurrency control schemes