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