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 = balance if balance1 < 0 then print “insufficient funds” abort T1 end write balance1 read balance2 balance2 = balance 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 if balance < 0 print “insufficient funds” abort T1 end write balance [ 0 ] Initial Balance = 100 Begin transaction T2 read balance [ 100 ] balance = balance 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 T1 read BalanceX BalanceX = BalanceX if BalanceX < 0 then begin print ‘insufficient funds’ abort T1 end write BalanceX read BalanceY BalanceY = BalanceY write BalanceY commit T1 T2 begin transaction T2 read BalanceX : read BalanceY commit 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