ConcurrencyConcurrency

Server accesses data on behalf of client– series of operations is a transaction– transactions are atomic

Several clients may invoke transactions on the same server.– transactions may be carried out sequentially– more efficient if transactions carried out

concurrently

ConcurrencyConcurrency Consider

– Transfer of £100 from account A to account B– Transfer of £200 from account C to account B

Operations (A Transaction)– read balance from source account– deduct amount– write balance to source account– read balance from destination account– add amount– write balance to destination account

B=£100

ConcurrencyConcurrency- lost update- lost update

A=£300

C=£600

Transaction Y

£100 from AB

• deduct £100

• add £100

Transaction Z

£200 from CB

• deduct £200

• add £200

• read from A

• write to A

A=£200 • read from C

• write to C

C=£400• read from B

• write to B

B=£200

• read from B

• write to B

B=£300

Concurrency Concurrency - lost update- lost update

Lost update Problem– occurred because

transaction Y had read C’s balance and was updating it transaction Z had read C’s balance whilst Y was updating it

– solution operate the transactions sequentially (slow) operate the transactions concurrently with the same outcome

as if they had been done sequentially

i.e.’serial equivalence’

Concurrency Concurrency - serial equivalence- serial equivalence

A=£300

B=£100

C=£600

Transaction Y

£100 from AB

• deduct £100

• add £100

Transaction Z

£200 from CB

• deduct £200

• add £200

• read from A

• write to A

A=£200 • read from C

• write to C

C=£400• read from B

• write to B

B=£200

• read from B

• write to B

B=£400

Concurrency Concurrency - inconsistent retrieval- inconsistent retrieval

A=£300

B=£100

C=£600

• deduct £100

• add £100

Transaction Z

Accounts balances’• read from A

• write to A

A=£200

• balance = A

• read from A

• read from B

• write to B

B=£200 • read from B

• balance +=B

• read from C

• balance +=C

Transaction Y

£100 from AB

balance = £900balance = £1000

Concurrency Concurrency - serial equivalence- serial equivalence

A=£300

B=£100

C=£600

• deduct £100

• add £100

Transaction Z

Accounts balances’• read from A

• write to A

A=£200

• balance = A

• read from A

• read from B

• write to B

B=£200 • read from B

• balance +=B

• read from C

• balance +=C

Transaction Y

£100 from AB

balance = £1000

Concurrency Concurrency - serial equivalence- serial equivalenceSerial Equivalence

– ensures consistent operation of transactions

Used as the basis for concurrency control– Implemented by:-

locking optimistic concurrency control timestamps

Concurrency ControlConcurrency Control - locking - locking

A=£300• read from A A=£300

B=£100

C=£600

Transaction Y

£100 from AB

• deduct £100

• add £100

Transaction Z

£200 from CB

• deduct £200

• add £200

• write to A

A=£200

C=£600

• read from C

• write to C

C=£400

B=£100

• read from B

• write to B

B=£200

• read from B locked - wait…...

• write to B

B=£400

Locked• ABORT

• restore original values

A=£300

B=£100

• COMMIT

Concurrency Control Concurrency Control - locking- lockingTransaction Y aborts

– returns to original values– overwrites one value from transaction Z– transaction Z commits

Solution– Use strict two phase locking

acquire locks during transaction (growing phase) release all locks when committed or aborted

(shrinking phase)

Concurrency ControlConcurrency Control - two phase - two phase lockinglocking

A=£300• read from A A=£300

B=£100

C=£600

Transaction Y

£100 from AB

• deduct £100

• add £100

Transaction Z

£200 from CB

• deduct £200

• write to A

A=£200

C=£600

• read from C

• write to C

C=£400

B=£100

• read from B

• write to B

B=£200

• read from B locked - wait…...

Locked• ABORT

• restore original values and unlock

A=£300

B=£100

• add £200

B=£100

• write to B

B=£300

• COMMIT & unlock

B=£300

C=£400

DISADVANTAGES OF THE DISADVANTAGES OF THE LOCKING MECHANISMLOCKING MECHANISM

Lock maintenance is an overhead.

The use of locks can result in a deadlock.

Preventing cascading aborts caused due to locking reduces concurrency.

Concurrency Control Concurrency Control - optimistic - optimistic concurrency controlconcurrency control

Locking has a high overhead.Use optimistic concurrency control

– based on the assumption that ‘the likelihood of two clients’ transactions accessing

the same data is low’

– proceed as if conflicts do not exist– keep tentative copies of data items– when completing transaction, validate data

before final write and committing.

PHASES OF THE PHASES OF THE TRANSACTIONTRANSACTION

Working (Read) Phase: Each transaction has a tentative version of the data item that it updates.o Read operationso Write operationso Read seto Write set Read operations are performed on committed versions of data items, so dirty reads

cannot occur.

PHASES OF TRANSACTIONPHASES OF TRANSACTION

• The Validation phase

On close transaction request, the transaction is validated to check for conflicts.

Successful validation – transaction commits.

Unsuccessful validation – conflict resolution is needed.

PHASES OF TRANSACTIONPHASES OF TRANSACTION

Update (Write) phase:

If transaction is validated, all changes recorded in tentative versions are made permanent.

Write transactions commit once the tentative versions of data items are recorded on permanent storage.

VALIDATION OF VALIDATION OF TRANSACTIONTRANSACTION

Uses the read/write rulesEnsures that scheduling of a transaction is

serially equivalent with respect to all other overlapping transactions.

Each transaction is assigned a transaction number when it enters the validation phase.

A transaction Ti always precedes a transaction Tj if i<j.

Validation test rulesValidation test rules

Ti Tj RuleRead 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.

Forms of ValidationForms of Validation

Backward validation

The read set of the transaction being validated is compared with the write sets of other transactions that have already committed.

• Forward validation

In forward validation of the transaction Tj the write set of Tj is compared with the read sets of all overlapping active transactions.

TIMESTAMP ORDERINGTIMESTAMP ORDERING

Each operation is validated when it is carried out.

Each transaction is assigned a unique timestamp value when it starts.

Requests from transactions can be totally ordered according to their timestamps.

TIMESTAMP ORDERING TIMESTAMP ORDERING RULERULE

Basic timestamp ordering rule is based on operation conflicts:

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.

TIMESTAMP ORDERING TIMESTAMP ORDERING RULERULE

The basic rule assumes that there is only one version of each object.

If each transaction has its own tentative version of each object is accesses, then multiple concurrent transactions can access the same object.

Deadlocks are avoided as transactions only wait for earlier ones.

Timestamp ordering…Timestamp ordering…

Each request by a transaction for a read or write operation on an object is checked to see whether it conforms to the operation conflict rules.

A request by the current transaction Tc can conflict with previous operations done by other transactions, Ti, whose timestamps indicate that they should be later than Tc.

Basic rulesBasic rules

Ti > Tc means Ti is later than Tc and Ti<Tc means Ti is earlier than Tc.

Rule Tc Ti 1. Write read Tc must not write an object that has been read by any Ti where Ti>Tc, this requires that Tc>= the maximum read timestamp of the object.

Rules…Rules…

Rule Tc Ti

2 Write write Tc must not write an object that

has been written by any Ti

where Ti > Tc, this requires that

Tc > write timestamp of the

committed object.

3 Read read Tc must not read an object that

has been written by any Ti where

Ti>Tc, this requires that Tc > write

timestamp of the committed object

Timestamp ordering write ruleTimestamp ordering write rule

By combining rules 1 & 2, we have the following rule for deciding whether to accept a write operation requested bt transaction Tc on object D:

if (Tc>=maximum read timestamp on D && Tc > write timestamp on committed version of D) perform write operation on tentative version of D

with write timestamp Tc else, Abort transaction Tc.

Timestamp ordering read ruleTimestamp ordering read rule

By using rule 3the following rule is used to decide whether to accept immediately, to wait or to reject a read operation requested by transaction Tc on object D :

if (Tc > write timestamp on committed version of D) { let Dselected be the version of D with the

maximum write timestamp <= Tc if (Dselected is committed) perform read operation on the version Dselected else wait until the transaction that made version Dselected commits or aborts then reapply the read rule.Else Abort transaction Tc.

Concurrency - SummaryConcurrency - Summary Why The problems

– lost update– inconsistent retrieval

The solution - serial equivalence (Concurrency Control)– locking– optimistic– time stamping

MULTIVERSION MULTIVERSION TIMESTAMP ORDERINGTIMESTAMP ORDERING

In multiversion timestamp ordering, a list of old committed versions as well as tentative versions is kept for each object. This list represents the history of values of the object. The benefit of using multiple versions is read operations that arrive too late need not be rejected.

Whenever a write operation is accepted, it is directed to a tentative version with write timestamp of the transaction. Whenever a read operation is carried out it is directed to the version with the largest write timestamp less than the transaction timestamp.

When a read arrives late, it can be allowed to read from an old committed version, so there is no need to abort late read operations

In multiversion timestamp ordering, read operations are always permitted, although they may have to Wait for earlier transactions to complete.

ComparisonsComparisons

Pessimistic Methods Timestamp ordering : decides the serialization order

statistically . Aborts the transaction immediately Locking: decides the serialization order dynamically.

Makes the transaction wait with the possible penalty of avoiding deadlock.

Optimistic concurrency control results in efficient operation when there are few

conflicts.