prepared by pradhyuman raol 114 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Prepared by: Pradhyuman Raol (114) PowerPoint Presentation
Download Presentation
Prepared by: Pradhyuman Raol (114)

Loading in 2 Seconds...

play fullscreen
1 / 11

Prepared by: Pradhyuman Raol (114) - PowerPoint PPT Presentation

  • Uploaded on

Locking Scheduler & Managing Hierarchies of Database Elements. Prepared by: Pradhyuman Raol (114). Managing Hierarchies of Database Elements. It Focus on two problems that come up when there id tree structure to our data.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Prepared by: Pradhyuman Raol (114)' - sal

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
prepared by pradhyuman raol 114

Locking Scheduler


Managing Hierarchies of Database Elements

Prepared by: PradhyumanRaol (114)

managing hierarchies of database elements

Managing Hierarchies of Database Elements

It Focus on two problems that come up when there id tree

structure to our data.

Tree Structure : Hierarchy of lockable elements. And How to allow locks on both large elements, like Relations and elements in it such as blocks and tuples of relation, or individual.

Another is data that is itself organized in a tree. A major example would be B-tree index.

locks with multiple granularity

Locks With Multiple Granularity

“Database Elements” : It is sometime noticeably the various elements which can be used for locking.

Eg: Tuples, Pages or Blocks, Relations etc.

Granularity locks and Types : While putting locks actually when we decide which database element is to be used for locking makes it separates in two types.

Types of granularity locks:

1) Large grained

2) Small grained

example bank database
Example: Bank database
  • Small granularity locks: Larger concurrency can achieved.
  • Large granularity locks: Some times saves from unserializable behavior.
three levels of database elements are as follows
Three levels of Database Elements are as follows:
  • Relations are the largest lockable elements
  • Each Relation is composed of one or more block or pages, on which its tuples are stored.
  • Each block contain one or more tuples.
warning locks

Warning locks

The solution to the problem of managing locks at different granularities involves a new kind of lock called a “Warning.“

It is helpful in hierarchical or nested structure .

It involves both “ordinary” locks and “warning” locks.

Ordinary locks: Shared(S) and Exclusive(X) locks.

Warning locks: Intention to shared(IS) and Intention to

Exclusive(IX) locks.

warning protocols

Warning Protocols

These are the rules to be followed while putting locks on

different elements.

1. To place an ordinary S or X lock on any element. we must

begin at theroot of the hierarchy.

2. If we are at the element that we want to lock, we need look

no further. We request lock there only

3. If the element is down in hierarchy then place warning lock

on that node respective of shared and exclusive locks and then

Move on to appropriate child and then try steps 2 or 3 and until

you go to desired node and then request shared or exclusive


compatibility matrix

Compatibility Matrix

IS column: Conflicts only on X lock.

IX column: Conflicts on S and X locks.

S column: Conflicts on X and IX locks.

X column: Conflicts every locks.

warning protocols1

Warning Protocols

Consider the relation:

M o v i e ( t i t l e , year, length, studioName)

Transaction1 (T1):


FROM Movie

WHERE title = 'King Kong';



SET year = 1939

WHERE title = 'Gone With the Wind';

phantoms and handling insertions

Phantoms and Handling Insertions

When transaction creates new sub elements of a lockable element, there are some opportunities to go wrong. The problem is that we lock only the existing items; there is no easy way to lock database elements that do not exist but might later be inserted.

Lets have transaction 3 (T3) to be executed:

SELECT SUM(length)

FROM Movie

WHERE studioName = ‘Disney’

But at the same time the transaction t4 inserts the new movie of

‘Disney’ studio. Then what happens if t3 gets executed and t4

afterwards that sum will be incorrect.

But solution could be we could treat the insert or delete transaction like

writing operation with exclusive locks at that time this problem gets