Distributed Database Management Systems: Lecture 29

Distributed Database Management Systems: Lecture 29. The main topics covered in this chapter include: locking based CC; timestamp ordering based CC; TM sends ops and other information to LM; LM checks the status of data item;...

Distributed Database Management Systems

Lecture 29

In the previous lecture

in DDBS

In this Lecture

• Locking based CC

• Timestamp ordering based CC.

• TM sends ops and

R2(x), W2(x), lr2(x), wl2(y), R2(y), W2(y),

lr2(y), C2,wl1(y), R1(y), W1(y), lr1(y), C1)

S={wl1(x), R1(x), W1(x), lr1(x),

wl2(x), R2(x), W2(x), lr2(x), wl2(y),

R2(y), W2(y), lr2(y), C2,wl1(y),

R1(y), W1(y), lr1(y), C1)

released

immediately-Two-Phase Locking

• A transaction must not

attain a lock once it

releases a lock

release any lock until

it is sure it won’t need any lock

• It creates growing

phase, shrinking phase and a lock point

end of growing phase

and start of shrinking

phase

Any transaction that follows 2-PL is

serializable

• This 2-PL is difficult to

implement

–LM has to know that a Tr

has attained all locks

–Its not going to need a

released item again

–So we have strict 2-PL

Centralized 2PL

designated to a single site

the Lock Manager

• Central site may

Coordinating TM

Primary Site LM

Data Processor Partic Site

Data Processor

Partic Site

Distributed 2-PL

• That was it about

locking approach

timestamp-based

concurrency control

• Timestamp then could

be a two tuple

consisting a counter

value and the site id

be used in stead

Timestamp Ordering Rule

• Given two conflicting

• TO scheduler checks

each operation against conflicting operations

allowed, older refused-

• A TO scheduler is

guaranteed to generate serial order

know all operations in

advance

• Practically, operations

come one at a time

of operations, a R/W

timestamp is allocated

to data items as well

• Data items assigned

rts(x) or wts(x), largest timestamp that has

read or written a data item

• For a write request, if

an older transaction

has read or written the data item, then

operation is rejected

• For a read request, if

an older transaction

has written the data

item, then operation is rejected

deadlocks

Conservative TO

• Basic TO generates too

many restarts

• Like, if a site is relatively

calm, then its transactions will be restarted again

and again

• Synchronizing

timestamps may be very costly

used if they are at

comparable speeds

• In con-TO, operations

are not executed

immediately, but they are buffered

queue for each TM

Multiversion TO

• Another attempt to

reduce the restarts

• Multiple versions of data items with largest r/w

stamps are maintained.

• Read operation is

performed from

appropriate version

older has read or

written a data item

That was all about

Pessimistic CC

algorithms, now we move to Optimistic approaches

Pessimistic assume

that conflicts are likely

to happen so they are careful and follow…

• Each transaction is divided

into sub-transactions that

execute independently

• Tij = Tr i that executes at site j

• Transactions run

independently at each site

until they reach end of read phases.

• VT1: If all transactions

Tk, where ts(Tk)<ts(Tij) have completed their

started its read,

validation succeeds

• VT2: If there is any Tk,

where ts(Tk)<ts(Tij) which completes its write while

Tij is in its read phase

then validation succeeds

if WS(Tk) ∩ RS(Tij) = Ø

• VT3: If Tk completes its read

phase before Tij completes its read phase, then validation

succeeds if

WS(Tk) ∩ RS(Tij) = Ø and WS(Tk) ∩ WS(Tij) = Ø

Tk

Tij

• Optimistic techniques

allow more

concurrency

the validation tests

longer transactions

• Here we have finalized our discussion on CC

techniques

• Next topic is Deadlock Management

• Locking based CC

generates deadlock

other way round

• A WFG represents the relationship between

transactions waiting for each other to release

data items

T7

• We can have local