distributed processing systems ( concurrency control ) 오 상 규 서강대학교 정보통신...
Post on 17-Jan-2016
219 Views
Preview:
TRANSCRIPT
Distributed Processing Systems
( Concurrency Control )
오 상 규오 상 규
서강대학교 정보통신 대학원 서강대학교 정보통신 대학원
Email : sgoh@macroimpact.comEmail : sgoh@macroimpact.com
Concurrency Control
서강대학교 정보통신 대학원
Transaction Transaction
Definition : a series of actions, carried out by a single user/application program, which must be treated as an individual unit.
ACID PropertiesAtomicity : A transaction must be all-or-nothing.Consistency : A transaction takes the system from one consistent state to another consistent.
Isolation : Although multiple transactions may execute concurrently, each transaction must be unaware of other transactions.
Durability : After a transaction completes successfully, the changes it has made to database persist, even if there are system failures.
Concurrency Control
서강대학교 정보통신 대학원
State Transition in the Transaction State Transition in the Transaction
Failed
Active
CommittedPartially
committed
Aborted
Active : the initial state, transaction stays in this state while it is executing.
Partially Committed : after the final statement has been executed.
Committed : after successful completion.
Failed : after the discovery that normal execution can no longer proceed.
Aborted : after the transaction has been rolled back, the database restored to its state prior to the start of the transaction.
Concurrency Control
서강대학교 정보통신 대학원
Need for Synchronization (Lost Update) Need for Synchronization (Lost Update)
$204B.Write(balance+4)
$203B.Write(balance+3)
$200balance := B.Read( )
$200balance := B.Read( )
$297C.Write(balance - 3)
$300balance := C.Read( )
$96A.Write(balance-4)
$100balance := A.Read( )
Bank$Deposit(B,3)Bank$Deposit(B,4)
Bank$Withdraw(C,3)Bank$Withdraw(A,4)
Transaction U :Transaction T :
Assume that account A,B,C have $100, $200, $300, respectively. The result is incorrect, increasing the balancing of account B by $4 instead of $7. U’update is lost because T overwrites it without seeing it
Incorrect
Concurrency Control
서강대학교 정보통신 대학원
Need for Synchronization (Inconsistent Retrieval) Need for Synchronization (Inconsistent Retrieval)
$300B.Write(balance + 100)
$200balance := B.Read()
$300+.balance := balance + C.Read()
$300balance := balance + B.Read()
$100balance := A.Read( )
$100A.Write(balance-100)
$200balance := A.Read( )
Bank$Deposit(B,100)
Bank$BranchTotal( )Bank$Withdraw(A,100)
Transaction U :Transaction T :
Assume that account A and B have all $200. The result includes the sum of A and B as $300, not $400. U’retrievals are inconsistent because T has performed only the withdrawal part of a
transfer at the time the sum is calculated.
Incorrect
Concurrency Control
서강대학교 정보통신 대학원
Solution to Inconsistent Retrieval Problem Solution to Inconsistent Retrieval Problem
$400+.balance := balance + C.Read()
$400balance := balance + B.Read()
$100balance := A.Read( )
$300B.Write(balance + 100)
$200balance := B.Read()
$100A.Write(balance-100)
$200balance := A.Read( )
Bank$Deposit(B,100)
Bank$BranchTotal( )Bank$Withdraw(A,100)
Transaction U :Transaction T :
We can avoid the inconsistent retrieval problem by performing all operations of transaction U
only after all operations of transaction T have terminated, as above. But, can decrease the performance
Correct
Concurrency Control
서강대학교 정보통신 대학원
Serial Equivalence (Serializability) Serial Equivalence (Serializability)
The use of serial equivalence as a criterion for correct concurrent execution prevents
the occurrence of lost updates and inconsistent retrievals. Concurrency control protocols should use this property to serialize transactions.
$207B.Write(balance+3)
$204balance := B.Read( )
$204B.Write(balance+4)
$200balance := B.Read( )
$297C.Write(balance - 3)
$300balance := C.Read( )
$96A.Write(balance-4)
$100balance := A.Read( )
Bank$Deposit(B,3)Bank$Deposit(B,4)
Bank$Withdraw(C,3)Bank$Withdraw(A,4)
Transaction U :Transaction T :
Correct
Concurrency Control
서강대학교 정보통신 대학원
Problems from Abort (Dirty Read) Problems from Abort (Dirty Read)
Abort transaction
Commit transaction
$108A.Write(balance + 5)
$103balance := A.Read( )
$103A.Write(balance+3)
$100balance := A.Read( )
Bank$Deposit(A,5)Bank.$Deposit(A,3)
Transaction U :Transaction T :
The transaction U will have seen a value that never existed, since A will be restored to its original value.
As the transaction U has committed, it cannot be undone.
Concurrency Control
서강대학교 정보통신 대학원
Problem from Abort (Premature Write) Problem from Abort (Premature Write)
Related to the interaction between Write operations on the same
data item belonging to different transactions
Before the transactions, the balance of account A was $100. Before image concept: before image of T’s write - $100, before image of U’s write - $3. T commits / U aborts (okay), U commits / T aborts (wrong balance). To ensure correct result, Write operations must be delayed until earlier transactions that updated the same data items have either committed or aborted.
$5A.Write(5)
$3A.Write(3)
Bank$SetBalance(A,5)Bank$SetBalance(A,3)
Transaction U :Transaction T :
Concurrency Control
서강대학교 정보통신 대학원
Problem from Abort (Cascading Abort) Problem from Abort (Cascading Abort)
A single transaction failure leads to a series of transaction rollbacks. Consider the following schedule where none of the transactions
has yet committed. (so the schedule is recoverable)
Read(A)Write(A)
T2
Write(A)Read(B)
Read(A)
Read(A)T3T1
If T1 fails, T2 and T3 must also be rolled back. Can lead to the undoing of a significant amount of work.
Page 11
Concurrency Control
서강대학교 정보통신 대학원
Strict Executions Strict Executions
Generally, it is required that transactions should delay both their Read
and Write operations so as to avoid both “dirty read” and “premature
write”.
The executions of transactions are called strict if the service delays both
Read and Write operations on a data item until all transactions that
previously wrote that data item have either committed or aborted.
The strict execution of transactions enforces the desired property of
isolation.
Page 12
Concurrency Control
서강대학교 정보통신 대학원
Tentative Versions Tentative Versions
A transaction must be designed so that any updates of the data items
can be removed if and when a transaction aborts.
All of the update operations performed during a transaction are done in
tentative versions of data items in volatile memory.
The tentative versions are transferred to the data items only when a
transaction commits, by which time they will also have been recorded in
permanent storage.
When a transaction aborts, its tentative versions are deleted.
Page 13
Concurrency Control
서강대학교 정보통신 대학원
Concurrency Control Concurrency Control
Transactions must be scheduled so that their effect on shared data is serially equivalent.
Serial equivalence requires that all of a transaction's accesses to a particular data item be serialized with respect to accesses by other transactions. Concurrency Control Protocols
Designed to cope with conflicts between operations in different transactions on the same data item.
A pair of operations conflicts : their combined effect depends on the order in which they are executed.
Page 14
Concurrency Control
서강대학교 정보통신 대학원
Three Concurrency Control Techniques (1) Three Concurrency Control Techniques (1)
Locking
The server sets a lock on each data item just before it is accessed and removes these locks when the transaction has completed.
While a data item is locked, only the transaction that it is locked for can access that item.
Other transactions must either wait until the item is unlocked or in some cases, share the lock.
The use of locks can lead to deadlock.
Page 15
Concurrency Control
서강대학교 정보통신 대학원
Three Concurrency Control Techniques (2) Three Concurrency Control Techniques (2)
Optimistic Concurrency Control
A transaction proceeds until it asks to commit.
Before it is allowed to commit, the server performs a check to discover whether it has performed operations on any data items that conflict with the operations of other concurrent transactions.
Timestamp Ordering
A server records the most recent time of reading and writing each data item and for each operation.
The timestamp of the transaction is compared with that of the data item to determine whether it can be done immediately, delayed or rejected.
Page 16
Concurrency Control
서강대학교 정보통신 대학원
Locks (1) Locks (1)
Two types of locks Read locks
• Before a transaction’s Read operation is performed, the server attempt to set a read lock on the data item.
Write locks • Before a transaction’s Write operation is performed, the server attempt to set a write lock on the data item.
A request for a write lock on a data item is delayed by the presence of read lock belonging to another transaction.
A request for either a read lock or a write lock on a data item is delayed by the presence of a write lock belonging to another transaction.
Page 17
Concurrency Control
서강대학교 정보통신 대학원
Locks (2) Locks (2)
Two modes of locks
Exclusive Mode : no other transaction can concurrently lock the data item.
Shared Mode : other transactions can lock the data item.
Lock compatibility
For one data item Lock requestedRead Write
Lock already set None OK OK
Read OK Wait
Write Wait Wait
Page 18
Concurrency Control
서강대학교 정보통신 대학원
Locks (3) Locks (3)
Inconsistent Retrievals (Refer to slide #5)
Caused by conflicts between Read operations in one transaction and Write operations in another.
Prevented by performing the retrieval transaction before or after the update transaction.
If the retrieval transaction comes first, its read locks delay the update transaction.
If it comes second, its request for read locks causes it to be delayed until the update transaction has completed.
Page 19
Concurrency Control
서강대학교 정보통신 대학원
Locks (4) Locks (4)
Lost Updates (Refer to slide #4)
Occur when two transactions read a value off data item and then use it to calculate a new value.
Prevented by making later transactions delay their reads until the earlier ones have completed.
This is achieved by each transaction setting a read lock when it reads a data item and then promoting it to a write lock when it writes the same data item. • Lock promotion : the conversion of a lock to a stronger lock.
Page 20
Concurrency Control
서강대학교 정보통신 대학원
Locking Mechanisms (1) Locking Mechanisms (1)
Lock all the objects required by a transaction at its start and to release them on commit or abort.
Two Phase Locking (2PL) Locks can be acquired as they are needed. No lock can be released until all locks have been acquired. Two Phase
First phase (growing phase) : A transaction may obtain locks, but may not release any lock. Second phase (shrinking phase) : A transaction may release locks, but may not obtain any new locks.
A transaction can release locks as it finishes with the associated objects. => may not safe.
A safe procedure is to release all locks on commit. => strict 2PL
Page 21
Concurrency Control
서강대학교 정보통신 대학원
Locking Mechanisms (2) Locking Mechanisms (2)
Strict Two Phase Locking (Strict 2PL)
Strict executions are needed to prevent dirty reads and premature writes.
Transaction that needs to read or write a data item must be delayed until other transactions that wrote the same data item have committed or aborted.
To enforce this rule, any locks applied during the progress of a transaction are held until the transaction commits or aborts.
When a transaction commits, the locks must be held until all the data items it updated have been written to permanent storage.
Guarantees that all conflicting pairs of operations of two transactions are scheduled in the same order. (serializable schedule of transactions.)
Page 22
Concurrency Control
서강대학교 정보통신 대학원
Use of Locks in Strict 2PL Use of Locks in Strict 2PL
1. When an operation accesses a data item within a transaction:
a) If the data item is not already locked, the server locks it and the
operation proceeds.
b) If the data item has a conflicting lock set by another transaction,
the transaction must wait until it is unlocked.
c) If the data item has a non-conflicting lock set by another transaction,
the lock is shared and the operation proceeds.
d) If the data item 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
data items it locked for the transaction.
Page 23
Concurrency Control
서강대학교 정보통신 대학원
Lock Implementation Lock Implementation
Lock Manager
Responsible for maintaining a table of locks for the data items of a server.
Entry in the table of locks
The transaction identifiers of the transactions that hold the lock. (shared locks can have several holders)
An identifier for a data item.
A lock type.
A condition variable. (Block the requester rather than retrying. Use wait and signal)
Page 24
Concurrency Control
서강대학교 정보통신 대학원
Lock Manager Functions Lock Manager Functions
Lock(Trans, DataItem, LockType)
if there is a conflicting lock, that is, if there is an entry in the table belonging to another transaction that conflicts with DataItem, Wait on the condition variable associated with the entry.
if (immediately or after a Wait) there are no conflicting locks: if there is no entry for DataItem, add an entry to the table of locks else if there is an entry for DataItem belonging to a different transaction, add Trans to the entry (share the lock) else if there is an entry for DataItem belonging to Trans and LockType is more exclusive than the type in the entry, change entry to LockType (promote lock).
Unlock(Trans)
if there are any entries in the table belonging to transaction Trans, for each entry :
if there is only one holder (Trans) in the entry, remove the entry
else (a shared lock) remove Trans from the entry and Signal the
associated condition variable.
Page 25
Concurrency Control
서강대학교 정보통신 대학원
Deadlocks Deadlocks
Deadlock
A state in which each member of a group of transactions is waiting for some other member to release a lock. Wait-for graph
Used to represent the waiting relationships between current transactions at a server.
• Nodes : transactions
• Edges : wait-for relationships between transactions
• There is an edge from node T to node U when transaction T is waiting for transaction U to release a lock.
Page 26
Concurrency Control
서강대학교 정보통신 대학원
Deadlock with Read and Write Locks Deadlock with Read and Write Locks
Transaction T : Transaction U :
Operations Locks Operations Locks
balance := A.Read( ) read locks A
balance := C.Read( ) read locks C
C.Write(balance-3) write locks C
A.Write(balance-4) write locks A
. . .
balance := B.Read( ) locks B
balance := B.Read( ) shares read
lock on B
B.Write(balance+4) wait for U
. . . B.Write(balance+3) wait for T
. . . . . .
Page 27
Concurrency Control
서강대학교 정보통신 대학원
The Wait-for Graph for Slide #26 The Wait-for Graph for Slide #26
TT UU TT UU
BB
AA CC
Held by Held by
Held by Held by
Waits for
If a wait-for graph contains a cycle, then all of these transactions are blocked waiting for locks. If one of the transactions in a cycle is aborted, then its locks are released and that cycle is broken.
Page 28
Concurrency Control
서강대학교 정보통신 대학원
Deadlock Prevention Deadlock Prevention
Lock all of the data items used by transaction when it starts.
An apparently simple, but not very good way.
It unnecessarily restricts access to shared resources.
It is sometimes impossible to predict at the start of a transaction which data items will be used.
Requesting locks on data items in a predefined order.
This can result in premature locking and reduction in concurrency.
Page 29
Concurrency Control
서강대학교 정보통신 대학원
Deadlock Detection Deadlock Detection
By finding cycles in the wait-for graph.
Deadlock detection software, part of the lock manager, must hold a representation of the wait-for graph so that it can check it for cycles.
Edges are added to the graph and removed from the graph by the lock manager's Lock and Unlock operations.
The presence of cycles may be checked each time an edge is added, or less frequently to avoid server overhead.
The choice of the transaction to abort is not simple.
Some factors : the age of the transaction, the number of cycles it is involved in.
Page 30
Concurrency Control
서강대학교 정보통신 대학원
Deadlock Resolution Deadlock Resolution
Lock timeouts
A method for resolution of deadlocks that is commonly used.
Each lock is given a limited period in which it is invulnerable. After this time, a lock becomes vulnerable.
If any transaction access the data item protected by a vulnerable lock, the lock is broken and the waiting transaction resumes. The transaction whose lock has been broken is normally aborted.
Problems with the use of timeouts Transactions are sometimes aborted due to their locks becoming
vulnerable when other transactions are waiting for them, but there is actually no deadlock. (in an overloaded system)
It is hard to decide on an appropriate length for a timeout.
Page 31
Concurrency Control
서강대학교 정보통신 대학원
Deadlock Resolution using Timeout Deadlock Resolution using Timeout
Transaction T : Transaction U :
Operations Locks Operations Locks
balance := A.Read( ) read locks A
balance := C.Read( ) read locks C
C.Write(balance-3) write locks C
A.Write(balance-4) write locks A
. . . . . .
balance := B.Read( ) read locks B
balance := B.Read( ) shares read lock on B
B.Write(balance+4) waits on U’s read lock on B
. . . B.Write(balance+3) waits on T’s read lock on B
timeout elapses . . .
T’s lock on B becomes vulnerable
unlocks B, abort T
B.Write(balance+3) write locks B / unlocks B, C
Page 32
Concurrency Control
서강대학교 정보통신 대학원
Optimistic Concurrency Control (OCC) Optimistic Concurrency Control (OCC)
The drawbacks of locking
Lock maintenance represents an overhead that is not present in systems that do not support concurrent access to shared data.
The use of locks can result in deadlock.
To avoid cascading aborts, locks cannot be released until the end of the transaction.
The alternative approach : Optimistic Concurrency Control
: It is based on the observation that, in most applications, the likelihood of two clients' transactions accessing the same data is low.
Page 33
Concurrency Control
서강대학교 정보통신 대학원
Three Phases in OCC (1) Three Phases in OCC (1)
Read phase
During the read phase, each transaction has a tentative version of each of the data items that it updates.
Read operations are performed immediately.
• If a tentative version for that transaction already exists, a read operation accesses it, otherwise it accesses the most recently committed value of the data item.
Write operations record the new values of the data items as tentative values. (internal to the transaction)
Page 34
Concurrency Control
서강대학교 정보통신 대학원
Three Phases in OCC (2) Three Phases in OCC (2)
Validation phase
When the CloseTransaction request is received, the transaction
is validated to establish whether or not its operations on data items
conflict with operations of other transactions on the same data items. Write phase
If a transaction is validated, all of the changes recorded in its
tentative versions are made permanent (commit). Otherwise,
rollback.
Page 35
Concurrency Control
서강대학교 정보통신 대학원
Validation of Transactions Validation of Transactions
Validation
Uses the Read/write conflict rules to ensure that the scheduling of a particular transaction is serially equivalent with respect to all other overlapping transactions.
To assist in performing validation, each transaction is assigned a transaction number in ascending sequence when it enters the validation phase. Transaction number defines its position in time.
As the validation and write phases of a transaction are generally short in duration compared with the read phase, a simplification may be achieved by making the rule that only one transaction may be in the validation and write phase at one time. (Rule 3 is satisfied.)
To prevent overlapping, the entire validation and write phases can be implemented as a critical section.
Page 36
Concurrency Control
서강대학교 정보통신 대학원
Read / Write Conflict Rules Read / Write Conflict Rules
Ti Tj Rule
Read Write 1. Ti must not read data items written by Tj.
Write Read 2. Tj must not read data items written by Ti.
Write Write
3. Ti must not write data items written by Tj
and Tj must not write data items written
by Ti.
Page 37
Concurrency Control
서강대학교 정보통신 대학원
Overlapping Transactions Overlapping Transactions
Read Validation Write
T1
T2
T3
Tj
active1
active2
Transaction being validated
Later active transactions
Earlier committed transactions
Page 38
Concurrency Control
서강대학교 정보통신 대학원
Backward Validation Backward Validation
Checks the transaction undergoing validation with other preceding overlapping transactions
The validation of transaction Tj checks whether its read set (the data items affected by the Read operations of Tj) overlaps with any of the write sets of earlier overlapping transactions Ti.
If there is any overlap, the validation fails. The read set of the transaction being validated is compared with the write sets of other transactions that have already committed. Transactions that have no Read operations need not be checked.
The write sets of old committed versions of data items corresponding to recently committed transactions are retained until there are no unvalidated overlapping transactions with which they might conflict.
Page 39
Concurrency Control
서강대학교 정보통신 대학원
Algorithm for Backward Validation Algorithm for Backward Validation
Algorithm for backward validation of Tj
startTn : the biggest transaction number assigned (to some other committed transaction) at the time when transaction Tj
started its read phase.
finishTn : the biggest transaction number assigned at the time when Tj
entered the validation phase.
Valid := TRUE ; FOR Ti := startTn +1 TO finishTn DO IF read set of Tj intersects write set of Ti THEN Valid := FALSE ; END END
Valid := TRUE ; FOR Ti := startTn +1 TO finishTn DO IF read set of Tj intersects write set of Ti THEN Valid := FALSE ; END END
Page 40
Concurrency Control
서강대학교 정보통신 대학원
Forward Validation Forward Validation
Forward validation
The write set of Tj compared with the read sets of all overlapping active transactions - those that are in still in their read phase. (Rule 1)
Read only transactions always pass the validation check. (Rule 2 is satisfied)
Some alternative way of resolving the conflict
Defer the validation until a later time when the conflicting transactions have finished.
Abort all the conflicting active transactions and commit the transaction being Validated.
Abort the transaction being validated.
Page 41
Concurrency Control
서강대학교 정보통신 대학원
Algorithm for Forward Validation Algorithm for Forward Validation
Algorithm for forward validation of Tj
active1, active2 : the active transactions have (consecutive) transaction identifiers.
Valid := TRUE ; FOR Tid:= active1 TO activeN DO IF write set of Tj intersects read set of Tid THEN Valid := FALSE ; END END
Valid := TRUE ; FOR Tid:= active1 TO activeN DO IF write set of Tj intersects read set of Tid THEN Valid := FALSE ; END END
Page 42
Concurrency Control
서강대학교 정보통신 대학원
Comparison of Two Approaches Comparison of Two Approaches
Forward validation
Allows flexibility in the resolution of conflicts.
Checks a small write set against the of read sets of active transactions.
Has to allow for new transactions starting during the validation process.
Backward validation
Allows only one choice - to abort the transaction being validated.
Compares a possibly large read set against the old write sets.
Has the overhead of storing old write sets until they are no longer needed.
Page 43
Concurrency Control
서강대학교 정보통신 대학원
Starvation Starvation
Starvation
: The deprivation of a transaction from ever being able to commit.
The server detects a transaction that has been aborted several times.
When the server detects such a transaction it should be given
exclusive access by the use of a critical section protected by
a semaphore.
Page 44
Concurrency Control
서강대학교 정보통신 대학원
Timestamp Ordering (1) Timestamp Ordering (1)
Each transaction is assigned a unique timestamp value when it starts. Timestamp : its position in the time sequence of transactions.
Using timestamps, requests from transactions can be totally ordered.
A server may use its clock to assign timestamps or it may use a 'pseudo-time‘ based on a counter.
Every data item has a write timestamp and a set of tentative versions, and a set of read timestamps.
Whenever a transaction's Write operation on a data item is accepted
the server creates a new tentative version of the data item with write
timestamp set to the transaction timestamp.
A transaction's Read operation is directed to the version with the
maximum write timestamp less than the transaction timestamp.
Page 45
Concurrency Control
서강대학교 정보통신 대학원
Timestamp Ordering (2) Timestamp Ordering (2)
Basic timestamp ordering rule based on operation conflicts
Write operations may be performed without making the client wait.
The client must wait when Read operations need to wait for earlier transactions to finish. (cannot lead to deadlock since transactions only wait for earlier ones.)
A transaction's request to write a data item is valid only if
that data item was last read and written by earlier transactions.
A transaction's request to read a data item is valid only if
that data item was last written by an earlier transaction.
A transaction's request to write a data item is valid only if
that data item was last read and written by earlier transactions.
A transaction's request to read a data item is valid only if
that data item was last written by an earlier transaction.
Page 46
Concurrency Control
서강대학교 정보통신 대학원
Timestamp Ordering (3) Timestamp Ordering (3)
Rule Tj
1. WriteTj must not write a data item that has been read by any Ti where Ti > Tj, this requires that Tj ≥ the maximum read timestamp of the data item.
2. WriteTj must not write a data item that has been written by any Ti where Ti > Tj, this requires that Tj > the maximum write timestamp of the committed data item.
3. ReadTj must not read a data item that has been written by any Ti where Ti > Tj, this implies that Tj cannot read if Tj < write timestamp of the committed version of the data item.
Transaction conflict for timestamp ordering
Page 47
Concurrency Control
서강대학교 정보통신 대학원
Timestamp Ordering Write Rule Timestamp Ordering Write Rule
If a tentative version with write timestamp Tj already exists, the Write operation is addressed to it, otherwise a new tentative version is created and given write timestamp Tj.
IF Tj ≥ maximum read timestamp on D AND Tj > write timestamp on committed version of D THEN perform Write operation on tentative version of D with timestamp Tj
ELSE (* write is too late *) Abort transaction Tj END
IF Tj ≥ maximum read timestamp on D AND Tj > write timestamp on committed version of D THEN perform Write operation on tentative version of D with timestamp Tj
ELSE (* write is too late *) Abort transaction Tj END
Page 48
Concurrency Control
서강대학교 정보통신 대학원
Write Operations and Timestamps Write Operations and Timestamps
T2T2Before
T2T2After T3T3
TIME
a) T3 Write
T2T2Before
T2T2After T3T3
TIME
c) T3 Write
T4T4
T4T4
T4T4Before
T4T4After
TIME
d) T3 Write
T1T1Before
T1T1After T2T2
TIME
b) T3 Write
T2T2
T3T3
: Committed ( ) / Tentative ( )data item produced by Ti, T1<T2<T3<T4TiTi TiTi
Transaction aborts
Page 49
Concurrency Control
서강대학교 정보통신 대학원
Timestamp Ordering Read Rule Timestamp Ordering Read Rule
IF Tj > write timestamp on committed version of D THEN let Dselected be the version of D with the maximum write timestamp ≤ Tj IF Dselected if committed THEN perform Read operation on the version Dselected
ELSE wait until the transaction that made version Dselected
commits or aborts then re-apply the read rule ELSE Abort transaction Tj
END
IF Tj > write timestamp on committed version of D THEN let Dselected be the version of D with the maximum write timestamp ≤ Tj IF Dselected if committed THEN perform Read operation on the version Dselected
ELSE wait until the transaction that made version Dselected
commits or aborts then re-apply the read rule ELSE Abort transaction Tj
END
Page 50
Concurrency Control
서강대학교 정보통신 대학원
Read Operations and Timestamps Read Operations and Timestamps
T2T2
TIME
a) T3 Read
T1T1
TIME
c) T3 Read
T2T2 T4T4
TIME
d) T3 Read
T2T2
TIME
b) T3 Read
T4T4
: Committed ( ) / Tentative ( )data item produced by Ti, T1<T2<T3<T4TiTi TiTi
Transaction aborts
Readproceeds
Readproceeds
Readwaits
Selected Selected
Selected
Page 51
Concurrency Control
서강대학교 정보통신 대학원
Recoverability Recoverability
Recoverability
In order to make a transaction recoverable after a server crash, the tentative versions of data items and the fact that the transaction has committed must be written to permanent storage before acknowledging the client's request to commit the transaction. A modification to the Timestamp Ordering Write rule
If a write is too late it can be ignored instead of aborting the transaction, because if it had arrived in time its effects would have been overwritten anyway. However, if another transaction has read the data item, the transaction with the late write due to the read timestamp on the item.
Page 52
Concurrency Control
서강대학교 정보통신 대학원
Timestamps in Transactions T and U Timestamps in Transactions T and U
Timestamps and versions of data items
Transaction T Transaction U A B C
RTS WTS RTS WTS RTS WTS
{ } S { } S { } S
OpenTransaction
bal : = A.Read( ) { T }
OpenTransaction
bal : = C.Read( ) { U }
A.Write(bal-4) S, T
bal : = B.Read( ) { T }
C.Write(bal-3) S, U
bal : = B.Read( ) { U }
B.Write(bal+4)
Aborts
B.Write(bal+3) S, U
Page 53
Concurrency Control
서강대학교 정보통신 대학원
Comparison of Three Methods (1) Comparison of Three Methods (1)
Pessimistic approaches
Serialization order
• Timestamp ordering method : decides the serialization order statically - when a transaction starts.
• Two-phase locking : decides the serialization order dynamically - according to the order in which data items are accessed.
Operational benefit • Timestamp ordering method : better than strict two-phase locking for read only transactions. • Two-phase locking : better when the operations in transactions are predominantly updates.
When a conflicting access • Timestamp ordering method : aborts the transaction immediately • Two-phase locking : makes the transaction wait
Page 54
Concurrency Control
서강대학교 정보통신 대학원
Comparison of Three Methods (2) Comparison of Three Methods (2)
Optimistic concurrency control
All transactions are allowed to proceed, but some are aborted when they attempt to commit, or in forward validation transactions are aborted earlier. • Relatively efficient operation when there are few conflicts.
• A substantial amount of work may have to be repeated when a transaction is aborted.
Two new requirement for multi-user applications
Users require immediate notification of changes made by other users.
Users need to be able to access data items before other users have completed their transactions
Page 55
Concurrency Control
서강대학교 정보통신 대학원
Comparison of Three Methods (3) Comparison of Three Methods (3)
Advanced database applications feature
Transactions last for a long time.
Users work on independent versions of data items that are checked out from a common database and checked in when the work is finished.
The merging of versions requires co-operation between user.
top related