View
220
Download
0
Tags:
Embed Size (px)
Citation preview
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 ?
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.