Concurrency 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

Concurrency 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 Concurrency - lost update A=£300 C=£600 Transaction Y £100 from A  B deduct £100 add £100 Transaction Z £200 from C  B 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 - 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 - serial equivalence A=£300 B=£100 C=£600 Transaction Y £100 from A  B deduct £100 add £100 Transaction Z £200 from C  B 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 - 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 A  B balance = £900balance = £1000

Concurrency - 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 A  B balance = £1000

Concurrency - serial equivalence Serial Equivalence – ensures consistent operation of transactions Used as the basis for concurrency control – Implemented by:- locking optimistic concurrency control timestamps

Concurrency Control - locking A=£300 read from A A=£300 B=£100 C=£600 Transaction Y £100 from A  B deduct £100 add £100 Transaction Z £200 from C  B 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 - locking Transaction 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 Control - two phase locking A=£300 read from A A=£300 B=£100 C=£600 Transaction Y £100 from A  B deduct £100 add £100 Transaction Z £200 from C  B 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 LOCKING 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 - optimistic concurrency 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 TRANSACTION Working (Read) Phase: Each transaction has a tentative version of the data item that it updates. o Read operations o Write operations o Read set o Write set Read operations are performed on committed versions of data items, so dirty reads cannot occur.

PHASES 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 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 TRANSACTION Uses the read/write rules Ensures 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 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.

Forms 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 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 RULE 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 RULE 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… 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 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… 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 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 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 - Summary Why The problems – lost update – inconsistent retrieval The solution - serial equivalence (Concurrency Control) – locking – optimistic – time stamping

MULTIVERSION TIMESTAMP 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.

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