Professional Documents
Culture Documents
Distributed Systems
But…
Transactions could run concurrently, i.e., with
multiple clients
Transactions may be distributed, i.e., across
multiple servers
Transaction Failure Modes
Transaction:
1. savings.deduct(100)
A failure at
A failure at these
2. checking.add(100) these points
points means the 3. mnymkt.deduct(200)does not cause
customer loses lost money, but
money; we need 4. checking.add(200) old steps
to restore old state cannot be
5. checking.deduct(400)
repeated
6. dispense(400)
7. commit
A failure after the
This is the point of commit point
no return (ATM crashes)
needs corrective
action; no undoing
possible.
Transactions in Traditional Databases (ACID)
Atomicity: All or nothing
Consistency: if the server starts in a consistent state, the
transaction ends the server in a consistent state.
Isolation: Each transaction must be performed without
interference from other transactions, i.e., the non-final effects
of a transaction must not be visible to other transactions.
Durability: After a transaction has completed successfully, all
its effects are saved in permanent storage.
Transaction T1 Transaction T2
balance = b.getBalance()
balance = b.getBalance()
b: 220
b.setBalance(balance*1.1)
b: 220
b.setBalance(balance*1.1)
a.withdraw(balance* 0.1) a: 80
c.withdraw(balance*0.1) c: 280
Transaction T1 Transaction T2
a.withdraw(100) a: 00 total
total = a.getBalance() 0.00
Transaction T1 Transaction T2
balance = b.getBalance() == T1 (complete) followed
by T2 (complete)
b.setBalance(balance*1.1)
b: 220
balance = b.getBalance()
b.setBalance(balance*1.1) b: 242
a.withdraw(balance* 0.1) a: 80
c.withdraw(balance*0.1) c: 278
Checking Serial Equivalence –
Conflicting Operations
The effect of an operation refers to
The value of an object set by a write operation
The result returned by a read operation.
Two operations are said to be conflicting operations, if their
combined effect depends on the order they are executed,
e.g., read-write, write-read, write-write (all on same variables).
NOT read-read, NOT on different variables.
Two transactions are serially equivalent if and only if all pairs
of conflicting operations (pair containing one operation from
each transaction) are executed in the same order (transaction
order) for all objects (data) they both access.
Why? Can start from original operation sequence and swap the order of
non-conflicting operations to obtain a series of operations where one
transaction finishes completely before the second transaction starts
Why is the above result important? Because: Serial equivalence is
the basis for concurrency control protocols for transactions.
Read and Write Operation Conflict
Rules
Operations of different Conflict Reason
transactions
Transaction T1 Transaction T2
balance = b.getBalance() == T1 (complete) followed
by T2 (complete)
b.setBalance(balance*1.1)
b: 220
balance = b.getBalance()
b.setBalance(balance*1.1) b: 242
a.withdraw(balance* 0.1) a: 80
c.withdraw(balance*0.1) c: 278
x= a.read()
a.write(20) Serially
z = a.read() equivalent
b.write(x) interleaving
of
y = b.read() operations
b.write(30)
(why?)
Inconsistent Retrieval Prob
Partial, incomplete results of one transaction are
retrieved by another transaction.
a: 100 b: 200 c: 300
Transaction T1 Transaction T2
a.withdraw(100) a: 00 total
total = a.getBalance() 0.00
TransactionT1: TransactionT2:
a.withdraw(100);
aBranch.branchTotal()
b.deposit(100)
a.withdraw(100); $100
In general:
Transactions should not violate operation conflict rules.
Concurrency control
Serial equivalence
criterion for correct concurrent execution
All pairs of conflicting operations of the two transactions are executed in the
same order at all objects that both transactions access.
• Transactions:
– Must be scheduled so that their effect on shared data is
serially equivalent
– Two types of approach
» Pessimistic If something can go wrong, it will
Operations are synchronized before they are carried
out
» Optimistic In general, nothing will go wrong
Operations are carried out, synchronization at the end
of the transaction
– Locks (pessimistic)
» can be used to ensuring serializability
» lock(x), unlock(x)
Locks: Basics
• Disadvantage of Locking
– Deadlocks
2PL
• Strict 2PL avoids Cascading Aborts
– A situation where a committed transaction has to be undone
because it saw a file it shouldn’t have seen.
• Problems of Locking
– Deadlocks
– Livelocks
» A transaction can’t proceed for an indefinite amount of time
while other transactions continue normally. It happens due
to unfair locking.
– Lock overhead
» If the system doesn’t allow shared access--wastage of
resources
– Avoidance of Cascading Aborts may be costly
» Strict 2PL in fact, reduces the effect of concurrency
Example: Concurrent Transactions
Exclusive Locks
Transaction T1 Transaction T2
OpenTransaction()
Lock
balance = b.getBalance() B OpenTransaction()
WAIT
on B balance = b.getBalance()
b.setBalance(balance*1.1) …
Lock
a.withdraw(balance* 0.1) A
…
CloseTransaction() UnLock Lock
B B
UnLock b.setBalance(balance*1.1)
A
Lock
c.withdraw(balance*0.1) C
UnLock
B
CloseTransaction()
UnLock
C
Basic Locking
Transaction managers (on server side) set locks
on objects they need. A concurrent trans. cannot
access locked objects.
No. of
Locks
Time
Locking Procedure in Strict-2P Locking
OpenTransaction()
balance = b.getBalance() R-Lock
OpenTransaction()
B R-
balance = b.getBalance() Lock
B
b.setBalance(balance*1.1)
Cannot Promote lock on B, Wait
Commit
Promote lock on B
…
Example: Concurrent Transactions
What happens in the example below?
Transaction T1 Transaction T2
OpenTransaction()
balance = b.getBalance() R-Lock
OpenTransaction()
B R-
balance = b.getBalance() Lock
B
b.setBalance(balance*1.1)
Cannot Promote lock on B, Wait
b.setBalance=balance*1.1
… …
Deadlock with write locks
TransactionT TransactionU
Operations Locks Operations Locks
b.withdraw(100)
waits for U’s a.withdraw(200); waits for T’s
lock on B lock on A
Waits for B
Held by
Deadlocks
Necessary conditions for deadlocks
Non-shareable resources (exclusive lock modes)
No preemption on locks
Hold & Wait or Circular Wait
A A
T U T V
B B
Transaction T Transaction U
Operations Locks Operations Locks
Disadvantages?
Strategies to Fight
Deadlock
Lock timeout (costly and open to false positives)
Deadlock Prevention: violate one of the necessary
conditions for deadlock (from 2 slides ago), e.g.,
lock all objects before transaction starts, aborting
entire transaction if any fails
Deadlock Avoidance: Have transactions declare
max resources they will request, but allow them
to lock at any time (Banker’s algorithm)
Deadlock Detection: detect cycles in the wait-for
graph, and then abort one or more of the
transactions in cycle
Optimistic Concurrency Control
(Kung and Robinson)
Validation of transactions
T1
Earlier committed
transactions
T2
T3
Transaction
being validated Tv
active
1
Later active
active
transactions 2
Validation Rules
Tv Ti Rule