distributed processing systems ( concurrency control ) 오 상 규 서강대학교 정보통신...

Distributed Processing Systems

( Concurrency Control )

오 상 규오 상 규

서강대학교 정보통신 대학원 서강대학교 정보통신 대학원

Email : [email protected] : [email protected]

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)


$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()




Bank$Deposit(B,100)

Bank$BranchTotal( )Bank$Withdraw(A,100)


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()


$300B.Write(balance + 100)

$200balance := B.Read()



Bank$Deposit(B,100)

Bank$BranchTotal( )Bank$Withdraw(A,100)


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.





$297C.Write(balance - 3)

$300balance := C.Read( )



Bank$Deposit(B,3)Bank$Deposit(B,4)

Bank$Withdraw(C,3)Bank$Withdraw(A,4)


Correct

Concurrency Control


Problems from Abort (Dirty Read) Problems from Abort (Dirty Read)

Abort transaction

Commit transaction

$108A.Write(balance + 5)


$103A.Write(balance+3)


Bank$Deposit(A,5)Bank.$Deposit(A,3)


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)


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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.)

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.

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)

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.

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.

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

. . . . . .

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.

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.

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.

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.

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

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.

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)

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.

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.

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.

Concurrency Control


Overlapping Transactions Overlapping Transactions

Read Validation Write

T1

T2

T3

Tj

active1

active2

Transaction being validated

Later active transactions

Earlier committed transactions

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.

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

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.

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

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.

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.

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.

Concurrency Control



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.

Concurrency Control



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

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

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

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

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

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.

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

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

Concurrency Control



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

Concurrency Control



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.

distributed processing systems ( concurrency control ) 오 상 규 서강대학교 정보통신...

Documents