Systems
Transactions
1
Transactions
Transactions
Operating Motivation Provide atomic operations at servers that maintain shared data for clients Provide recoverability from server crashes Properties Atomicity, Consistency, Isolation, Durability (ACID) Concepts: commit, abort
Transactions
2
1
Operations of the Account interface
deposit(amount) deposit amount in the account withdraw(amount) withdraw amount from the account getBalance() -> amount return the balance of the account setBalance(amount) set the balance of the account to amount Operations of the Branch interface create(name) -> account create a new account with a given name lookUp(name) -> account return a reference to the account with the given name branchTotal() -> amount return the total of all the balances at the branch
Transactions 3
A clients banking transaction
Transaction T: a.withdraw(100); b.deposit(100); c.withdraw(200); b.deposit(200);
Transactions
4
2
Operations in Coordinator interface
openTransaction() -> trans; starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction. closeTransaction(trans) -> (commit, abort); ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted. abortTransaction(trans); aborts the transaction.
Transactions
5
Transaction life histories
Successful openTransaction operation operation
Aborted by client openTransaction operation operation server aborts transaction
Aborted by server openTransaction operation operation
operation closeTransaction
operation abortTransaction
operation ERROR reported to client
Transactions
6
3
Concurrency control
Motivation: without concurrency control, we have lost
updates, inconsistent retrievals, dirty reads, etc. (see following slides) Concurrency control schemes are designed to allow two or more transactions to be executed correctly while maintaining serial equivalence
Serial Equivalence is correctness criterion
Schedule produced by concurrency control scheme should be equivalent to a serial schedule in which transactions are executed one after the other
Schemes: locking, optimistic concurrency control, time-
stamp based concurrency control
We will only study locking in this class
Transactions
7
The lost update problem
TransactionT : balance = b.getBalance(); b.setBalance(balance*1.1); a.withdraw(balance/10) balance = b.getBalance(); $200
TransactionU: balance = b.getBalance(); b.setBalance(balance*1.1); c.withdraw(balance/10) balance = b.getBalance(); $200 b.setBalance(balance*1.1); $220
b.setBalance(balance*1.1); $220 a.withdraw(balance/10) $80 c.withdraw(balance/10) $280
Transactions
8
4
The inconsistent retrievals problem
Transaction V: a.withdraw(100) b.deposit(100) a.withdraw(100); $100 total = a.getBalance() total = total+b.getBalance() total = total+c.getBalance() b.deposit(100) $300 $100 $300 TransactionW: aBranch.branchTotal()
Transactions
9
A serially equivalent interleaving of T and U
TransactionT: balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) balance = b.getBalance() $200 b.setBalance(balance*1.1) $220 balance = b.getBalance() $220 b.setBalance(balance*1.1) $242 a.withdraw(balance/10) $80 c.withdraw(balance/10) $278 TransactionU: balance = b.getBalance() b.setBalance(balance*1.1) c.withdraw(balance/10)
Transactions
10
5
A serially equivalent interleaving of V and W
TransactionV: a.withdraw(100); b.deposit(100) a.withdraw(100); b.deposit(100) $100 $300 total = a.getBalance() total = total+b.getBalance() total = total+c.getBalance() ... $100 $400 TransactionW: aBranch.branchTotal()
Transactions
11
Read and write operation conflict rules
Operations of different Conflict transactions read read No
Reason Because the effect of a pair of readoperations does not depend on the order in which they are executed Because the effect of a read and a write operation depends on the order of their execution Because the effect of a pair of write operations depends on the order of their execution
read write
write write
Yes Yes
Transactions
12
6
A non-serially equivalent interleaving of operations of transactions T and U
Transaction T: x = read(i) write(i, 10)
Transaction U:
y = read(j) write(j, 30) z = read (i)
write(j, 20)
Transactions
13
A dirty read when transaction T aborts
TransactionT: a.getBalance() a.setBalance(balance + 10) balance = a.getBalance() $100 balance = a.getBalance() $110 TransactionU: a.getBalance() a.setBalance(balance + 20)
a.setBalance(balance + 10) $110 a.setBalance(balance + 20) $130 commit transaction abort transaction
Transactions
14
7
Transactions T and U with exclusive locks
Transaction T : balance = b.getBalance() b.setBalance(bal*1.1) a.withdraw(bal/10) Operations Locks Transaction U : balance = b.getBalance() b.setBalance(bal*1.1) c.withdraw(bal/10) Operations Locks
openTransaction bal = b.getBalance() lock B b.setBalance(bal*1.1) a.withdraw(bal/10) closeTransaction lock A unlockA, B lock B b.setBalance(bal*1.1) c.withdraw(bal/10) lock C closeTransaction unlockB, C
Transactions 15
openTransaction bal = b.getBalance() waits forTs lock onB
Lock compatibility
For one object Lock already set none read write
Lock requested read write OK OK wait OK wait wait
Transactions
16
8
Use of locks in strict two-phase locking
1. When an operation accesses an object within a transaction: (a) If the object is not already locked, it is locked and the operation proceeds. (b) If the object has a conflicting lock set by another transaction, the transaction must wait until it is unlocked. (c) If the object has a non-conflicting lock set by another transaction, the lock is shared and the operation proceeds. (d) If the object has already been locked in the same transaction, the lock will be promoted if necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock, rule (b) is used.) 2. When a transaction is committed or aborted, the server unlocks all objects it locked for the transaction.
Transa...