Feb 7, 2008 - The notes contain many proofs, and you're not expected to memorise these. However the exam questions ...... for the disjunction of the n truth values t1, à¸à¸à¸ ,tn; this is true if one or more of the truth values is true, ...... Pag
referring to models, and thread when referring to an implementation in Java.
Threads in Java. A Thread class manages a single sequential thread of control.
Lecture 7: Enhanced Concurrency in Java. • java.util.concurrent: – Semaphore
class. – Interface Lock/ Class Condition. – Bounded Buffers Implementation.
John C. Hull, Options, Futures & other Derivatives (Fourth. Edition), Prentice Hall
... Calibrate them, and compute prices of European and American. Options. 2 ...
Scissor Lift Platform ... Work done by a force of 1 Newton moving through a
distance of 1 m in the direction .... internal forces holding together parts of a rigid
body.
Connection setup. ◇ Flow control: resource exhaustion at end node. ○. Today:
Congestion control. ◇ Resource exhaustion within the network. 2 ...
Jun 25, 2009 ... Yikes: Celine Dion dressed as Michael Jackson performing “Bad” in a ... Sony
released several greatest hits compilations, which put MJ back ...
Ar礬t Development. – e礦ue e coaching (for the ladies), media training,
choreography and styling. • Songwri瓏g and Development. – Holland/Dozier/
Holland.
“Concurrency,” as this is often called, can be an ... Concurrency requirements (
also called adequate ... There are seven major objectives of a concurrency
system ...
The Nutrition Transition. Benjamin Caballero, M.D., Ph.D. Center for Human
Nutrition. Johns Hopkins Bloomberg School of Public Health ...
Lecture 15: Nonlinear adaptive systems. • Adaptive feedback linearization. •
Adaptive backstepping design. • Adaptive forwarding design c Leonid Freidovich.
May 13, 2009 ... L15 Wavelets and multiresolution ... The signals are undistinguishable in the
Fourier domain. .... Wavelets in MATLAB (not mandatory). 1.
Active Resource. – What does it do? – How do you use it? – Web 2.0 “Features”. ▫
Prototype and Scriptaculous. ▫ Issues Encountered. ▫ Conclusions. ▫ Demo's.
LECTURE 15: FOURIER METHODS. ⢠We discussed different bases for regression in lecture. 13: polynomial, rational, splin
Illustrate some properties of the boundary layer in Stokes first problem. 3. ... Ema
9: H 3.28 696 ...... H. Schlichting, Boundary-Layer Theory, 7th ed., McGraw-.
CS 373: Theory of Computation. ˜. Sariel Har-Peled and Madhusudan
Parthasarathy. Lecture 15: CYK Parsing Algorithm. 3 March 2009. 1 CYK parsing.
Mar 11, 2014 ... cryptographic hash functions. • The most commonly used ... http://csrc.nist.gov/
publications/fips/fips180-2/fips180-2.pdf. The SHA-512 algorithm ...
State Models and Java Programs. Jeff Magee and ... for programs which interact
with the environment, control multiple ... programming practice in Java. Java is.
Jan 1, 2006 ... Preface. These notes are intended for the introductory finance course ... of
finance theory and often cover continuous-time modelling, such as Duffie3 .....
Theorem 2 The security market (π, C) is arbitrage-free if and only if there
Ellin Oliver Keene has been a classroom teacher, staff developer, non-profit ... overseeing IRA's Literacy Research Pane
Although circular motion sounds kind ... body depends on understanding a kind
of circular motion. ... Note that in angular problems counterclockwise is positive.
Calculating the posterior probability, p({Ri,ui}N i=1|I) using Bayes' Rule, and then calculating the MAP estimate is equ
Microprocessor-based System Design. Ricardo Gutierrez-Osuna. Wright State
University. 1. Lecture 15: Memory and I/O interface g Address space g Memory ...
Serial & serialisable schedules. • For more information: • Connolly and Begg
chapter 20. In This Lecture. • More Concurrency fun that you can shake a stick at:.
Last Lecture More Concurrency Database Systems Lecture 15
• Concurrency • Locks and resources • Deadlock • Serialisability • Schedules of transactions • Serial & serialisable schedules • For more information: • Connolly and Begg chapter 20
In This Lecture • More Concurrency fun that you can shake a stick at: • Serialisability • Precedence graphs • Two phase locking • Protocols, Serialisability theorem
• Timestamping
• For more information
Concurrency So Far • We want to run transactions concurrently: • • • • •
Schedules Serial schedules Equivalence Correctness Serialisability
• To prevent some problems we use locking protocols: • • • • •
• A `schedule' is the actual execution sequence of two or more concurrent transactions.
• Remember if a schedule is serialisable we know it is going to be correct. (give us a consistent database as a result)
• A schedule of two transactions T1 and T2 is `serialisable' if and only if executing this schedule has the same effect as either T1;T2 or T2;T1.
• In order to know that a particular transaction schedule is serialisable, we can draw a precedence graph.
• We like serialisable schedules!
• The schedule is said to be serialisable if and only if there are no cycles in the resulting diagram.
1
Precedence Graphs • To determine if a schedule is serialisable we use a precedence graph: • Transactions are vertices of the graph • Directional arcs are drawn between conflict operations • The schedule will then be serialisable (and hence correct) if there are no cycles
Precedence Graph Example Lost update schedule: T1 must reads X before T2 writes X
T1
T1
T2
T2 must read X before T1 writes X
T2
Precedence Graph To draw one: 1) Draw a node for each transaction in the schedule 2) For each pair of following ordered conflict operations in S, create a directional arc in the same order Ti Tj W(X) R(X) create arc Ti -> Tj R(X) W(X) create arc Ti -> Tj W(X) W(X) create arc Ti -> Tj
Precedence Graph Example • A serial version of the transactions has the graph
Read(X) X = X - 5 Read(X) X = X + 5 Write(X)
T1
T2
Read(X) X = X – 5 Write(X) T1
Read(X) X = X +
T2
5 Write(X)
COMMIT
T1 reads X before T2 writes X
Write(X) COMMIT
COMMIT
Two-Phase Locking • The mere presence of locks does not guarantee serialisability.
COMMIT
Two-Phase Protocol • The two-phase locking protocol:
• That is all locks that are going to be opened do so, before any are closed.
1) lock-acquisition phase: Before operating on any item, a transaction must acquire at least a shared lock on that item. Thus no item can be accessed without first obtaining the correct lock.
• If all transactions obey the `two-phase locking protocol', then all possible interleaved executions are guaranteed serialisable.
2) lock-release phase: After releasing a lock, a transaction must never go on to acquire any more locks.
• Locking only guarantees this if it is two phased.
2
2PL Example T1 is two-phased - all of its locks are acquired before it releases any of them
Serialisability Theorem T2 is not - it releases its lock on X and then goes on to later acquire a lock on Y
• A schedule of two-phased transactions might not be deadlock free, but if it is…
Any schedule of two-phased transactions is conflict serialisable i.e. it gives us the same results as a serial version of the schedule, and hence is correct!
Serialisability Theorem • A schedule of twophased transactions is either conflict serialisable or results in deadlock • This relationship is captured in the waitfor and precedence graphs
Similarities
• Wait-for graph
• Precedence graph
• A cycle indicates deadlock
• Each transaction is a vertex
• Each transaction is a vertex
• Precedence graph
• Arcs from T1 to T2 if
• Arcs from T2 to T1 if
• A cycle indicates the schedule is not conflict serilisable
• For two-phased transactions these are the same thing.
T1 Read(X) T2 Read(Y) T1 Write(X) T2 Read(X) T3 Read(Z) T3 Write(Z) T1 Read(Y) T3 Read(X) T1 Write(Y)
T1 T2 reads X after T1 writes X
T2
T3
Wait for graph
T1 must go before T2
T1 T2
T3
Precedence graph
3
Example T1 Read(X) T2 Read(Y) T1 Write(X) T2 Read(X) T3 Read(Z) T3 Write(Z) T1 Read(Y) T3 Read(X) T1 Write(Y)
Example T1
T3 reads X after T1 writes X
T2
T3
Wait for graph
T1 must go before T3
T1 T2
T3
T1 Read(X) T2 Read(Y) T1 Write(X) T2 Read(X) T3 Read(Z) T3 Write(Z) T1 Read(Y) T3 Read(X) T1 Write(Y)
T1 T1 writes Y after T2 reads Y
• Deadlock can still arise with 2PL • Deadlock is less of a problem than an inconsistent DB • We can detect and recover from deadlock • It would be nice to avoid it altogether
• Conservative 2PL • All locks must be acquired before the transaction starts • Hard to predict what locks are needed • Low ‘lock utilisation’ transactions can hold on to locks for a long time, but not use them much
Timestamping • We’ve seen Transactions can be run concurrently using a variety of techniques: • Two phase locking • Wait-for and precedence graphs • Deadlock prevention
• An alternative is timestamping • Requires less overhead in terms of tracking locks or detecting deadlock • Determines the order of transactions before they are executed
T3
Wait for graph
T2 must go before T1
Precedence graph
Deadlock Prevention
T2
T1 T2
T3
Precedence graph
Deadlock Prevention • We impose an ordering on the resources • Transactions must acquire locks in this order • Transactions can be ordered on the last resource they locked
• This prevents deadlock: • If Tx is waiting for a resource from Ty then that resource must come after all of Tx ’s current locks • All the arcs in the wait-for graph point ‘forwards’ - no cycles
Timestamping • Each transaction has a timestamp, TS, and if Tx starts before Ty then: TS(Tx ) < TS(Ty ) • Can use the system clock or an incrementing counter to generate timestamps
• At any point in time each resource has two timestamps • R(X), the largest timestamp of any transaction that has read X • W(X), the largest timestamp of any transaction that has written X
4
Timestamp Protocol • Now If a transaction, T tries to read X: • If TS(T) < W(X) T is rolled back and restarted with a later timestamp • If TS(T) ≥ W(X) then the read succeeds and we set R(X) to be max(R(X), TS(T))
• And if a transaction T tries to write X: • If TS(T) < W(X) or TS(T) < R(X) then T is rolled back and restarted with a later timestamp. • Otherwise the write succeeds and we set W(X) to TS(T)
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
X
Y
Z
R W
Timestamping Example • Given T1 and T2 lets assume: • The transactions make alternate operations • Timestamps are allocated from a counter starting at 1
T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
• T1 goes first
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
X R
T1 T2 TS 1
TS
Timestamp Example T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
X R
Z
W
T1 T2
T1
Y
1
Y
2
W T1 T2 TS 1
2
Z
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
R
X
Y
2
1
Z
W T1 T2 TS 1
2
5
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
X R
2
Y
Z
2
W
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
R
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
R
X
Y
2
2
Z
2
Timestamp Example T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
R
X
Y
2
2
Z
W T1 T2
rollback
TS 3
2
2
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
Uh oh. Y has a read Timestamp on it that is greater than T1’s
T1 T2
T1
2
TS 1
W
TS 1
2
Z
T1 T2
2
Timestamp Example T1
Y
W
T1 T2 TS 1
X
R
X
Y
2
2
Z
W T1 T2 TS 1
2
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
R
X
Y
2
2
W
Z 2
T1 T2 TS 3
2
New timestamp
6
Timestamp Example T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
R
X
Y
3
2
W
Z T1 2
T1 T2 TS 3
Timestamp Example
Read(X) Read(Y) Y=Y+X Write(Y)
T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
X
Y
3
3
W
• Equivalent to running transactions in order of their final time values • Transactions don’t wait - no deadlock!
Read(X) Read(Y) Z=Y-X Write(Z)
3
T1 T2
2
R
T1
T2
Read(X) Read(Y) Y=Y+X Write(Y)
Read(X) Read(Y) Z=Y-X Write(Z)
X
Y
3
3
W
3
Z 2
T1 T2 TS 3
2
Transaction Summary ACID Properties
• Problems
• Rolls back old transactions, which may have done a lot of work
2
Timestamp Example
2
• Long transactions might keep getting restarted by new transactions – starvation.
Z
T1 T2
Z
Timestamping • The protocol means that transactions with higher times take precedence:
3
TS 3
2
TS 3
Y
W
2
Timestamp Example
R
R
T2
X
Recovery
Concurrency
Schedules Serialisability
Transaction Manager
Locking 2PL
Deadlock
Timestamping
7
Next Lecture • Database Security • Aspects of security • Access to databases • Privileges and views
