If 2 or more transaction are made 2 execute concurrently then they should result in a consistent state after the execution of all the transactions same as prior to their execution i.e they should be serializable schedule.

A number of concurrency control techniques are applied in a concurrent database and one type of technique is locking the data item to prevent multiple transaction from accessing the items concurrently.

Another set of protocol use timestamp.Locking technique: A lock is a variable associated

with each data item that describes the status of the item with respect to possible operations that can be applied to it.

Types of lock: depending upon types of lock the data manager gives or denies access to other operations on the same data item

Binary Locks: will have 2 values locked and unlocked represented as 0 and 1.

A transaction sends a request to a datamanager to access to a dataitem by first locking the data item using LOCK() operation .At this moment if any other operation of some other concurrent

transcation tries to access same data item then it is forced to wait untill the transaction (previous one) that has locked the dataitem unlock the data item using unlocked command.

Few rules must be followed when binary locking technique is used.

LOCK() : operation must be issued by transaction before any update operation like read() or write() operation are performed on transaction.

LOCK() :can’t be issued by transaction if already holds LOCK() on data item

UNLOCK() : must be issued after all read() and write() operations are completed in a transaction.

UNLOCK(): can’t be issued by transaction unless it already hold the lock on the data item.

Example for binary lock T1:LOCK(A) T1:READ(A) A=100 T1:A:=A+200 A=300 T1:WRITE(A) T1:UNLOCK(A) T2:LOCK(A) T2:READ(A)

A=300 T2:A:=A+300 A=600 T2:WRITE(A) A=600 T2:UNLOCK(A)

This example is seriazible schedule.Therefore, in case of a binary locking mechanism atmost one transaction can hold the lock on a particular dataitem .Thus no transaction can access the same item concurrently.

Lock-Based ProtocolsA lock is a mechanism to control concurrent access to a

data itemData items can be locked in two modes : 1. exclusive (X) mode. Data item can be both read as

well as written. X-lock is requested using lock-X instruction. In simplest manner if a transaction Ti has obtained an

exclusive mode lock on data item X then Ti can both read and

write data item Q. In other words if a transaction locks a data item and

no other transaction can access that item or even read untill

the lock is released by the transaction then such type of locking

mechanism is Exclusive

It is also called a write lock

2. shared (S) mode. Data item can only be read. S-lock is

requested using lock-S instruction.Lock requests are made to concurrency-control

manager. Transaction can proceed only after request is granted.

In other way if a transaction Ti has obtained a shared mode lock on item X then Ti can read but can’t write data item X

Few rules must be followed when read/write locking technique is used.

LOCK() : operation must be issued by transaction before any update operation like read() or write() operation are performed on transaction.

LOCK() :can’t be issued by transaction if already holds LOCK() on data item

UNLOCK() : must be issued after all read() and write() operations are completed in a transaction.

UNLOCK(): can’t be issued by transaction unless it already hold the lock on the data item.

Lock-Based Protocols

Lock-compatibility matrix

A transaction may be granted a lock on an item if the requested lock is compatible with locks already held on the item by other transactions

Any number of transactions can hold shared locks on an item, but if any transaction holds an exclusive on the item no other transaction may hold any lock on the item.

If a lock cannot be granted, the requesting transaction is made to wait till all incompatible locks held by other transactions have been released. The lock is then granted.

Example of a transaction performing locking:

T1 LOCKX(A) READ(A) A=1000 A:=A-200 A=800 WRITE(A) A=800 UNLOCK(A) LOCKX(B) READ(B) B=900 B:=B+200 B=1100 WRITE(B) B=1100 UNLOCK(B)

T2 LOCKX(SUM) SUM:=0 LOCKS(A) READ(A) A=800 SUM:=SUM+A SUM=800 UNLOCK(A) LOCKS(B) READ(B) B=1100 SUM:=SUM+B SUM=1900 WRITE(SUM) SUM=1900 UNLOCK(B) UNLOCK(SUM) IF EXECUTED SERIALLY THE

OUTPUT WILL BE 1900

BUT IF RUNNING CONCURREENTLY THEN SUM WILL BE 2100 i.e LOSS UPDATE

T2:LOCKX(SUM) T2:SUM:=0 T2:LOCKS(A) A=1000 T2:READ(A) T2:SUM:=SUM+A

SUM=1000 T2:UNLOCK(A) T1:LOCKX(A) T1:READ(A) A=1000 T1:A:=A-200 A=800 T1:WRITE(A) A=800 T1:UNLOCK(A) T1:LOCKX(B) T1:READ(B) B=900 T1:B:=B+200 B=1100

T1:WRITE(B) B=1100 T1:UNLOCK(B) T2:LOCKS(B) T2:READ(B) B=1100 T2:SUM:=SUM +B

SUM=1100T2:WRITE(SUM) SUM=1100

T2:UNLOCK(B)

T2:UNLOCK(SUM) AFTER TRANSACTION

SUM+B IS 2100 .This is inconsistent. This locking technique didn’t solve this problem because value of a/c A was added to sum before modification was

Consider another example

T1 LOCKX(B) READ(B) B=200 B:=B-50 B=150 WRITE(B) B=150 UNLOCK(B) LOCKX(A) READ(A) A=100 A:=A+50 A=150 WRITE(A) A=150 UNLOCK(A) T2: LOCKS(A) READ(A) A=150

UNLOCK(A) LOCKS(B) READ(B) B=150 UNLOCK(B) DISPLAY(A+B) A+B=300 THIS IS CLEAR THAT IF

THEY RUN SEQUENTIALLY THE OUT PUT WILL BE 300

WHEN TRANSACTION ARE RUNNING CONCURRENTLY

T1 LOCKX(B) READ(B) B=200 B:=B-50 B=150 WRITE(B) B=150 UNLOCK(B)

T2 LOCKS(A) READ(A) A=100 UNLOCK(A) LOCKS(B) READ(B) B=150 UNLOCK(B) DISPLAY(A+B)A+B=250

T1 LOCKX(A) READ(A) A=100 A:=A+50 A=150 WRITE(A) A=150 UNLOCK(A) THIS IS AN INCONSISTENT

STATE OUTPUT WILL BE 250

NOW IF WE DELAY UNLOCKING TO THE END OF TRANSACTION THEN

T1 LOCKX(B) READ(B) B=200 B:=B-50 B=150 WRITE(B) B=150 LOCKX(A) READ(A) A=100 A:=A+50 A=150 WRITE(A) A=150 UNLOCK(B) UNLOCK(A)

T2 LOCKS(A)

READ(A) A=150 LOCKS(B) READ(B) B=150 UNLOCK(A) UNLOCK(B) DISPLAY(A+B) HERE ALSO A+B WILL BE

300

Pitfalls of Lock-Based Protocols

Consider the partial schedule

Neither T3 nor T4 can make progress — executing lock-S(B) causes T4 to wait for T3 to release its lock on B, while executing lock-X(A) causes T3 to wait for T4 to release its lock on A.

Such a situation is called a deadlock. To handle a deadlock one of T3 or T4 must be rolled

back and its locks released.

DEAD LOCK:

In other words a dead lock occurs when each transaction in a set of 2 or more transaction is waiting for some data item which is locked by other transaction in a set i.e two transaction are waiting for a condition that will never occur.

The main reason for deadlock is exclusive locks acquired on data item by a transaction

The potential for deadlock exists in most locking protocols. Deadlocks are a necessary evil.

Pitfalls of Lock-Based Protocols (Cont.)

Starvation is also possible if concurrency control manager is badly designed. For example:A transaction may be waiting for an X-lock on an item, while a

sequence of other transactions request and are granted an S-lock on the same item.

The same transaction is repeatedly rolled back due to deadlocks.For an example T2 has a shared mode lock on data item A and

T1 request an exclusive lock on data item A,T1 can’t be given that lock untill T2 releases shared lock on data item A .But if T3 request a shared lock on A it will be given .At this moment if T2 releases its lock on A,still T1 will have to wait for T3 to finish.In a similar way there may exist a sequence of transactions requesting shared lock on data item A and each releases its lock a short while after it is granted ,But T1 will never get the exclusive lock on data item A.Thus T1 will never progress and such situation is starvation

Concurrency control manager can be designed to prevent starvation.

This is a protocol which ensures conflict-serializable schedules.

Avoiding starvation:It can be avoided by granting the locks in

following manner.When a transaction Ti request a lock on data item A in a particular mode M the database manager grants the lock provided that

1.There is no other transaction holding a lock on data item A in a mode that conflicts with M.

2.There is no other transaction that is waiting for a lock on A and that made its lock request before Ti

Two phase lockingPhase 1: Growing Phase

transaction may obtain locks transaction may not release locks

Phase 2: Shrinking Phase transaction may release locks transaction may not obtain locks

The Two-Phase Locking:The protocol assures serializability. It can be proved that the transactions can be serialized in the order of their lock points (i.e. the point where a transaction acquired its final lock). T1

READ(B) B:=B-50 WRITE(B) UNLOCK(B) LOCKX(A) READ(A) A:=A+50 WRITE(A) UNLOCK(A) Above example is not 2

phase because unlock(b) appears before lock(a)

T1 READ(B) B:=B-50 WRITE(B) LOCKX(A) READ(A) A:=A+50 WRITE(A) UNLOCK(B) UNLOCK(A) Above example is 2 phase

because unlocks appears after all lock operation

Two-phase locking does not ensure freedom from deadlocks

Cascading roll-back is possible under two-phase locking. To avoid this, follow a modified protocol called strict two-phase locking. Here a transaction must hold all its exclusive locks till it commits/aborts.

This requirement ensures that any data written by uncommitted transaction are locked in exclusive mode untill the transaction commits,preventing any other transaction from reading the data.

Rigorous two-phase locking is even stricter: here all locks are held till commit/abort. In this protocol transactions can be serialized in the order in which they commit.

Conversion of locks:TRANSACTION ARE RUNNING CONCURRENTLY T1

READ(A) READ(B) …. …. …. WRITE(A) T2 READ(A) READ(B) DISPLAY(A+B)

If we are following 2 phase locking protocol the transaction T1 must lock data item in exclusive mode as it has to perform write operation on item A.

The other transaction T2 just need to read the data item A but is unable to get shared lock on item A untill T1 perform write operation on A1.Since T1 needs an exclusive lock on A only at the end of its execution where it perform write operation on A it will be better if T1 could initially lock A1 in shared mode and later on chages lock to exclusive mode at that time when it has to perform write operation.if we do so then both transaction can share a and b data item together .

A mechanism is provided for upgrading a shared lock to exclusive lock and downgrading an exclusive lock to a shared lock.

Conversion from shared to exclusive modes is denoted by upgrade

Conversion from exclusive to shared mode by downgrade.

Lock conversion is not allowed to occur arbitrarily.Upgrading takes place only in growing phase whereas downgrading takes place in only shrininking phase

T1LOCKS(A)LOCKS(B)READ(A)READ(B)UPGRADE(A)….WRITE(A)

Thus the final scheme for automatic generation of an appropiate lock and unlock instruction for a transaction is as follows

When a trnsaction Ti issues a READ(A) operation it issue a locks(A) instruction followed by READ(A) instruction

When a transaction Ti issues a write(A) operation the system check to see whether Ti has already hold a shared lock on data item A. If yes the system will issue an upgrade(A) instruction followed by write(A).

Otherwise the system will issue a LOCKX(A) instruction followed by write(a) instruction

All locks obtained by transaction are unlocked after the transaction commit or abort

Implementation of LockingA Lock manager can be implemented as a separate

process to which transactions send lock and unlock requests

The lock manager replies to a lock request by sending a lock grant messages (or a message asking the transaction to roll back, in case of a deadlock)

The requesting transaction waits until its request is answered

The lock manager maintains a datastructure called a lock table to record granted locks and pending requests

The lock table is usually implemented as an in-memory hash table indexed on the name of the data item being locked

Lock Table

Black rectangles indicate granted locks, white ones indicate waiting requests

Lock table also records the type of lock granted or requested

New request is added to the end of the queue of requests for the data item, and granted if it is compatible with all earlier locks

Unlock requests result in the request being deleted, and later requests are checked to see if they can now be granted

If transaction aborts, all waiting or granted requests of the transaction are deleted lock manager may keep a list of

locks held by each transaction, to implement this efficiently

Insert and Delete Operations

If two-phase locking is used :A delete operation may be performed only if the transaction

deleting the tuple has an exclusive lock on the tuple to be deleted.

A transaction that inserts a new tuple into the database is given an X-mode lock on the tuple

Insertions and deletions can lead to the phantom phenomenon.A transaction that scans a relation (e.g., find all accounts in

Perryridge) and a transaction that inserts a tuple in the relation (e.g., insert a new account at Perryridge) may conflict in spite of not accessing any tuple in common.

If only tuple locks are used, non-serializable schedules can result: the scan transaction may not see the new account, yet may be serialized before the insert transaction.

Insert and Delete Operations

The transaction scanning the relation is reading information that indicates what tuples the relation contains, while a transaction inserting a tuple updates the same information. The information should be locked.

One solution: Associate a data item with the relation, to represent the

information about what tuples the relation contains.Transactions scanning the relation acquire a shared lock in

the data item, Transactions inserting or deleting a tuple acquire an

exclusive lock on the data item. (Note: locks on the data item do not conflict with locks on individual tuples.)

Above protocol provides very low concurrency for insertions/deletions.

Index locking protocols provide higher concurrency while preventing the phantom phenomenon, by requiring locks on certain index buckets.