1 term 2, 2004, lecture 6, transactionsmarian ursu, department of computing, goldsmiths college...
TRANSCRIPT
![Page 1: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/1.jpg)
1
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Transactions
3
![Page 2: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/2.jpg)
2
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Outline
transactions - generalities concurrency control
concurrency problems locking
![Page 3: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/3.jpg)
3
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
1
![Page 4: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/4.jpg)
4
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Transactions – example
Parts (P_id, P_name, Colour, Weight, Total_qty) Contracted (S_id, P_id, Qty) add a new contract for ‘S4’ for 200 pieces of ‘P1’
P_id P_name Colour Weight Total_qty
P1 gear white 1.233 1150P2 pin black 0.1 10000… … … … …
S_id P_id Qty
S1 P1 500S1 P3 200S2 P1 150S3 P1 500S3 P2 1000
![Page 5: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/5.jpg)
5
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Transaction
logical unit of work sequence of database operations
transforms a consistent state of a db into another consistent state
between operations the db can be inconsistent
![Page 6: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/6.jpg)
6
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Transaction Processing
do not allow for one operation to be performed and the other ones not
principle of transaction processing support if some operations are executed and then a failure occurs
(before the planned termination) then those operations will be undone
![Page 7: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/7.jpg)
7
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Transaction Manager
COMMIT TRANSACTION• a logical unit of work was successfully completed
• all the updates can be made permanent
ROLLBACK TRANSACTION• unsuccessful end of transaction
• all the attempted updates must be rolled back
they are issued from applications
![Page 8: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/8.jpg)
8
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Example
execute(BEGIN TRANSACTION);
execute(INSERT (‘S4’, ‘P1’, 200) INTO Contracted);if(/*any error occurred*/) then go to undo;
execute( UPDATE Parts WHERE P_id =‘P1’ SET Total_qty = Total_qty + 200);
if(/*any error occurred*/) then go to undo;
execute(COMMIT TRANSACTION);go to finish;
undo : execute(ROLLBACK TRANSACTION);finish : return;
![Page 9: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/9.jpg)
9
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
SQL Support
COMMIT and ROLLBACK No BEGIN TRANSACTION (in SQL2 and Oracle)
all data definition and data manipulation statements are transaction initiating
PostgreSQL provides BEGIN [TRANSACTION]
![Page 10: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/10.jpg)
10
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
At the COMMIT point
all updates, since the previous commit, are made permanent (will not be undone)
all database positioning and all tuple locks are lost
![Page 11: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/11.jpg)
11
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
ACID Properties of Transactions
Atomicity• all or nothing
Consistency• preserve database consistency
Isolation• transactions are isolated from one another
Durability• committed transaction updates are performed
![Page 12: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/12.jpg)
12
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
2
![Page 13: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/13.jpg)
13
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Concurrency
more than one transaction have access to data simultaneously
![Page 14: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/14.jpg)
14
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Three concurrency problems
the lost update the uncommitted dependency the inconsistent analysis
![Page 15: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/15.jpg)
15
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
The lost update problem
Transaction A time Transaction B
RETRIEVE (t) t1
t2 RETRIEVE (t)
UPDATE (t) TO (t1) t3
t4 UPDATE (t) TO (t2)
![Page 16: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/16.jpg)
16
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
The uncommitted dependency problem
Transaction A time Transaction B
t1 UPDATE (t)
RETRIEVE (t) t2
t3 ROLLBACK
![Page 17: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/17.jpg)
17
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
The uncommitted dependency problem
Transaction A time Transaction B
t1 UPDATE p
UPDATE p t2
t3 ROLLBACK
![Page 18: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/18.jpg)
18
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
The inconsistent analysis problem
Transaction A time Transaction B
BEGIN TRANSACTION t0RETRIEVE (SugarA) t1
[sum = 500] t2 BEGIN TRANSACTION t3 RETRIEVE (SugarA)
RETRIEVE (SugarB) t4 UPDATE SugarA TO 0 [sum = 700] t5 COMMIT
RETRIEVE (SugarC) t6[sum = 800]
end result: sum = 800
![Page 19: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/19.jpg)
19
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Issue
all these problems may lead to an inconsistent (incorrect) database
is there a criterion based on which to decide weather a certain set of transaction, if executed concurrently, leads to an incorrect database or not?
![Page 20: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/20.jpg)
20
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Serialisability
criterion for correctness for concurrent execution of transactions: the interleaved execution of a set of transactions is
guaranteed to be correct if it is serialisable correct the DB is not in an inconsistent state serialisability: an interleaved execution has the same result
as some serial execution
![Page 21: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/21.jpg)
21
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Serialisable schedule
Interleaved schedule for transaction 1, 2 and 3
time t1 t2 t3 t4 t5 t6 t7 t8 t9Transaction 1 op11 op12 op13 op14Transaction 2 op21 op22 op23Transaction 3 op31 op32
Equivalent serial schedule (Transaction 1 then Transaction 3 then Transaction 2)
time t1 t2 t3 t4 t5 t6 t7 t8 t9Transaction 1 op11 op12 op13 op14Transaction 2 op21 op22 op23Transaction 3 op31 op32
![Page 22: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/22.jpg)
22
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Notes
the schedules described in the concurrency problems examples were not serialisable neither A-then-B nor B-then-A
two different interleaved transactions might produce different results, yet both can be considered correct
![Page 23: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/23.jpg)
23
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
3
![Page 24: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/24.jpg)
24
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Two-phase locking theorem
if all transactions obey the two phase locking protocol then all possible interleaved schedules are serialisable
• i.e., they can be executed concurrently, because they will leave the database in a consistent state
![Page 25: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/25.jpg)
25
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Two-phase locking protocol
1.before operating on an object a transaction must acquire a lock on that object
2.after releasing a lock a transaction must not go on to acquire any more locks
• phase1 (growing): acquire locks (not simultaneously)
• phase2 (shrinking): release locks (no further acquisitions allowed)
• usually locks are released by the COMMIT or ROLLBACK operation
in practice • trade-off between “release lock early and acquire more locks”
and the “two phase locking protocol”
![Page 26: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/26.jpg)
26
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Locking
usually, applicable to tuples types
• X, exclusive - write
• S, shared - read
rules• compatibility matrix
![Page 27: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/27.jpg)
27
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Compatibility matrix
existing lock on trequest for lock on t X S none
X refused refused granted
S refused granted granted
no request - - -
![Page 28: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/28.jpg)
28
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Data access protocol
retrieve tuple acquire S lock (on that tuple) update tuple acquire X lock (on that tuple), or
promote the S lock it holds (if it holds one)• implicit request
if request for lock is denied transaction goes in wait state until the lock is released
• livelock - first come first served
X locks are held until end of transaction (COMMIT or ROLLBACK) (two phase locking protocol)
![Page 29: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/29.jpg)
29
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
The uncommitted dependency problem: OK
Transaction A time Transaction B
t1 UPDATE (t)(X lock on t)
RETRIEVE (t) t2 (request X lock on t) wait t3 COMMIT / ROLL..wait (release X lock on t)resume RETRIEVE (t) t4 (acquire S lock on t)
![Page 30: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/30.jpg)
30
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
The lost update problem : dead-lock
Transaction A time Transaction B
RETRIEVE p t1 (acquire S lock on p)
t2 RETRIEVE p (acquire S lock on p)
UPDATE p t3 (request X lock on p denied) t4 UPDATE p wait (request X lock on p wait denied) wait wait
![Page 31: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/31.jpg)
31
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Locking
solves the three basic problems of concurrency theorem
• if all the transactions of a set S of transactions comply with the two phase locking protocol, then all their possible interleaved executions (schedules) are serialisable
• however, not all schedules produce the same result– think of examples
introduces another problem: deadlock
![Page 32: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/32.jpg)
32
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Deadlock
two or more transaction are waiting for the other to release a lock
• in practice: usually two transactions
detect a deadlock • cycle in the wait-for graph, or
• timing mechanism
break a deadlock• rollback a victim transaction
• what happens to the victim?
![Page 33: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/33.jpg)
33
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Further topics
• two phase locking protocol - not feasible in practice (not efficient)
levels of isolation• degree of interference
intent locking• locking granularity
SQL support• no explicit locking facilities
• it supports different isolation levels (with “locking behind the scenes”)
![Page 34: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/34.jpg)
34
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
–
![Page 35: 1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3](https://reader036.vdocuments.mx/reader036/viewer/2022070305/5515c7ff550346a3758b49b8/html5/thumbnails/35.jpg)
35
Term 2, 2004, Lecture 6, Transactions Marian Ursu, Department of Computing, Goldsmiths College
Conclusions
transactions concurrency
concurrency problems locking