Desirable features implementation

How to cope with multiple users conducting simultaneous

transactions

Transactions

• In the Builder system we have written transactions to:– Add an order:

• Maybe add a customer• Add an order• Add one or more order lines to the order• Confirm (commit) or abandon (rollback) the order)

– Ship an order:• Confirm that the stock has been handed over to the

customer.

• We have identified other transaction requirements.

Problem

• Fred wants to put in a order for:– Kevin Quinn– To buy:

• 40 planks of wood 6mx.3m

• 10 boxes of 100 4cm nails

• Joe wants to put in a new order for:– Adam O’Connor– To buy

• 20 planks of wood 6mx.3m

• 1 door frame• 6 brass hinges

There are only 50 planks of wood (6mx.3m) in stock. Who gets them?

If it is a single-user system

– Fred will put in his order and the stock-level for the planks of wood will go down to 10.

– Joe will try to order 20 planks and won’t be allowed.

• OR– Joe will put in his order and stock-level for the planks

of wood will go down to 20.– Fred will try to order 40 planks and won’t be allowed.

• But what if they are both working at the same time?

Concurrency Control

• Transaction– the basic unit of work in a DBMS

• Properties of a transaction– ATOMICITY– CONSISTENCY– INDEPENDENCE– DURABILITY

A.C.I.D properties (1)

• Atomicity– the is the “all or nothing” property ; a

transaction is an indivisible unit of work

• Consistency– transactions transform the DB from one

consistent state to another consistence state

A.C.I.D properties (2)

• Independence– transactions execute independently of one

another i.e. the partial effect of one transaction is not visible to other transactions.

• Durability (aka Persistence)– the effect of a successfully completed (i.e.

committed) transaction are permanently recorded in the DB and cannot be undone.

Example Transaction

• Funds transfer :

begin transaction T1

read balance1

balance1 = balance1 - 100

if balance1 < 0then print “insufficient funds”

abort T1

end

write balance1

read balance2

balance2 = balance2 + 100

write balance2

commit T1

Discussing the Example

• Effect of the abort is to rollback the transaction and undo changes it has made on the DB

• in this example, transaction was not written to the DB prior to abort and so no undo is necessary

Problems with Concurrency

• Concurrent transaction can cause three kinds of database problems– Lost Update– Violation of Integrity Constraints– Inconsistent Retrieval

Lost Update

• Apparently successful updates can be overwritten be other transactions

Begin transaction T1

read balance [ 100 ]

balance = balance - 100

if balance < 0

print “insufficient funds”

abort T1

end

write balance [ 0 ]

Initial Balance = 100

Begin transaction T2

read balance [ 100 ]

balance = balance + 100

write balance [ 200 ]

commit T2

Inconsistent Retrieval (Dirty Reads)

• Most concurrency control systems focus on the transactions which update the DB since they are the only ones which can corrupt the DB.

• If transaction are allowed to read the partial results of incomplete transactions, they can obtain an inconsistent view of the DB (dirty or unrepeatable reads).

Inconsistent Retrieval (Dirty Reads)

T1

begin transaction T1read BalanceXBalanceX = BalanceX - 100if BalanceX < 0 thenbeginprint ‘insufficient funds’abort T1endwrite BalanceXread BalanceYBalanceY = BalanceY + 100write BalanceYcommit T1

T2

begin transaction T2read BalanceX::::::::::::read BalanceYcommit T2

Concurrency Control

• Schedules and Serialisation

• Order in a schedule is VERY important

• S = [R1(x), R2(x), W1(x), W2(x)]– Where S is the schedule– R is a read– W is a write

• so, is it O.K. to do reads before or after writes, e.g. Lost Update Problem ?

Conflicting Operations

• If two transactions only read a data item, they do not conflict and order is not important.

If two transactions either read or write completely separate data items, they do not conflict and order is not important.

If one transactions writes a data item and another transaction reads or writes the same data item, the order of execution is important.

How does concurrency work?

In fact, the operations are run serially anyway, but the operations from the two transactions are merged into one.

If you can merge two transactions, then they can be serialised – i.e. they

are serialisable.

Serial Schedule

• What is a serial schedule ?• In the following example, • R/W1 refers to operations from transaction 1.• R/W2 refers to operations from transaction 2.• S is the serial version of these.• S = [R1(X), W1(X), R2(X), W2(X), R3(X)]• In this case,

– Transaction 1 is conducted first– Transaction 2 is then conducted, followed by– Transaction 3.

• Even though they all operate on a field X, they are serialised.

Serialisable Schedule

• What is a Serialisable schedule ?

• S = [R1(x), R2(x),W1(x), R3(x), W2(x)]

• Is this Serialisable ?

General Solution

• Constrained Write Rule

• Transaction should always Read before they Write

Rules for Equivalence of Schedules

• Each read operation must read the same values in both schedules; – this effectively means that those values must have

been produced by the same write operation in both schedules

• The final state of the database must be the same in both schedules; – thus the final write operation on each data item is the

same in both schedules

Try these...

• [R1(x), W1(x), R2(x), W2(x)]

• [R1(x), R2(x), W1(x), W2(x)]

• [R1(x), R3(y), R2(x), W2(z), W2(y), W1(x), R2(y), W1(z)]

Conflicting Operations

• Read operations cannot conflict with one and other, thus the order of read operations does not matter.

i.e. [R1(x), R2(x)] = [R2(x), R1(x)]

• but[R1(x),W1(x),R2(x)] != [R1(x), R2(x), W1(x)]

Conflicting Operations

• In terms of schedule equivalence, it is the ordering of CONFLICTING operators which must be the same in both schedules.

• The conflict between read and write operations is called a read-write conflict and the conflict between two writes is called a write-write conflict.

Concurrency Control Techniques

• There are three basic concurrency control techniques :

• Locking Methods

• Timestamp Methods

• Optimistic Methods