A MultiGranularity Locking Model

1
A Multi-Granularity Locking Model

• For Concurrency Control in OODBMS
• Suh-Yin Lee Ruey-Long Liou

2
The Track

• Multi-Granularity (Background)
• General Locking Model (DBMS)
• OODBMS Considerations (Topic of the Paper)
• ORION Locking Model
• Comparison
• Summary

3
Multi-Granularity

• Granularity Size of the objects to be locked.
• Different levels mean different sizes
• e.g. Table is at higher granularity level than
  the tuples it contains.
• Why do we need different levels of granularities
  ?
• To support higher degree of concurrency with
  fewer number of locks and thus minimizing the
  locking overhead.
• We have 3 options when it comes to
  granularities.

4
Option - 1 Single lock

• To read a tuple, lock the whole table.
• No differentiation of granularity levels.
  Accessing a tuple is same as
• accessing the table.
• Fewest number of locks, lowest degree of
  concurrency

Granule
Table
5
Option - 2 One lock per tuple

• To read a tuple, acquire the lock associated
  with the tuple.
• As many locks as tuples.
• No different levels of granularities. Have to
  acquire a lock per tuple.
• Highest degree of concurrency.
• Very high locking overhead.

Granules
Tuples
6
Option - 3 Combine 1 2

• One lock for the whole table and a lock for each
  tuple.
• Acquire the table lock if many tuples need to be
  accessed.
• Acquire the tuple locks to access individual
  tuples.
• Different levels of granularities.
• Higher level of concurrency.
• Less locking overhead - Have to follow the
  locking protocol.

Granule at level 1
Granules at level 2
Tuples
Table
7
The Problem with Option - 3

• There is no association between different
  granularity locks.
• May result in inconsistency when same resource
  (the table) is accessed by multiple threads at
  different levels of granularities.
• The solution (Protocol)
• Acquire intention locks on all greater levels of
  granules before acquiring the needed lock on the
  desired level.
• Note
• No thread will acquire a tuple lock before
  acquiring an intention lock
• on the table itself.
• The smallest granules have no intention lock
  semantics. They are
• higher than no level !!

8
The Track

• Multi-Granularity (Background)
• General Locking Model (DBMS)
• OODBMS Considerations (Topic of the Paper)
• ORION Locking Model
• Comparison
• Summary

9
General Locking Model

• IS Intention Shared
• Some tuple of this table is being read from
• IX Intention Exclusive
• Some tuple of this table is being written to
• S Shared
• Whole table may be read from (for Level 1)
• This tuple is being read from (for Level 2)
• SIX Shared Intention Exclusive
• Whole table is being read from and some tuple is
  being written to
• X Exclusive
• Whole table may be written to (for Level 1)
• This tuple is being written to (for Level 2)

10
Compatibility Matrix

• N means not compatible, Blank means compatible

11
Examples

• Reading a tuple
• Acquire IS on the table containing the tuple
• Acquire S on the tuple
• Read all tuples and write one tuple
• Acquire SIX on the table
• Acquire X on the tuple to write
• So whats left ? We seem to be able to do
  everything now
• OODBMS has many other conflicting properties
  which need special handling

12
The Track

• Multi-Granularity (Background)
• General Locking Model (DBMS)
• OODBMS Considerations (Topic of the Paper)
• ORION Locking Model
• Comparison
• Summary

13
OODBMS Considerations

• The mapping
• Table Each class is a table
• Tuple Each instance of the class is a tuple of
  that table
• Fields Attributes of the object are the fields
  in the tuple
• Schema and Instances are distinct but related
• Restricted concurrency
• Inheritance, Multiple inheritance
• Have to lock subclasses and update their schema
  if the schema
• changes
• Composite and component objects
• Implicit locks on component objects if composite
  object is being
• accessed
• Have to handle all of these for concurrency!!

14
An Example
Class CompositeClass Vehicle car Owner
xyz Class Vehicle int make int
ID Class Owner char name char
SSN main() CompositeClass c1,
c2 Vehicle car1, car2
15
Problems

• Exclusive
• The component object can only be part of a
  single
• composite object
• Dependent
• If a composite object is deleted, all its
  component objects
• are also deleted
• This assumptions are too restrictive. In fact
  there can be situations like
• Dependent Exclusive reference
• Independent Exclusive reference
• Dependent Shared reference
• Independent Shared reference
• Does the general model work here ?

16
Conflicts in OODB

• Instance-Instance conflict
• Instance-Schema conflict
• Schema-Schema conflict

Class Level
CompositeClass
Vehicle
make
Owner
car xyz
ID
name
SSN
Instance Level
c1
c2
c3
17
The Track

• Multi-Granularity (Background)
• General Locking Model (DBMS)
• OODBMS Considerations (Topic of the Paper)
• ORION Locking Model
• Comparison
• Summary

18
ORION Locking Model

• Instances (Objects) S and X modes
• Classes (Schemas) S, X, IS, IX and SIX modes

19
Composition support

• Exclusive component instance ISO, IXO and SIXO
  modes
• Shared component instance ISOS, IXOS and SIXOS
  modes

composite1
composite2
car1
owner1
car2

• Owner owner1 has two Cars car1 and car2
• owner1 is a shared reference between composite1
  and composite2
• car and car2 are exclusive references

20
An Example

• Read composite1 instance of CompositeClass
• lock CompositeClass in IS mode
• lock composite1 in S mode
• lock Vehicle class in ISO mode
• lock Owner class in ISOS mode

IS
CompositeClass
composite1
composite2
S
owner1
car2
car1
Vehicle
Owner
ISO
ISOS
21
Observations

• owner1 and car1 were never locked
• This restricts the degree of concurrency
• Redundancy in the compatibility matrix
• This increases the number of modes unnecessarily

22
Observations

• owner1 and car1 were never locked
• This restricts the degree of concurrency
• Redundancy in the compatibility matrix
• This increases the number of modes unnecessarily

23
Observations

• owner1 and car1 were never locked
• This restricts the degree of concurrency
• Redundancy in the compatibility matrix
• This increases the number of modes unnecessarily

24
The Track

• Multi-Granularity (Background)
• General Locking Model (DBMS)
• OODBMS Considerations (Topic of the Paper)
• ORION Locking Model
• Comparison
• Summary

25
Comparison (Our protocol)

• Read composite1 instance of CompositeClass
• lock CompositeClass in IS mode
• lock Vehicle class in IS mode
• lock Owner class in IS mode
• lock composite1 in S mode
• lock car1 in S mode
• lock owner1 in S mode
• Only basic modes
• Higher degree of concurrency - ISO and IX are
  allowed now
• Understandability, complexity
• Two more locks to acquire
• Thinking one granularity level at a time (SIX
  Vs. U)

26
Summary

• OODBMS brings its own problems for concurrency
• ORION model takes care of composition
• It can be improved greatly
• Its not a distributed mutual exclusion protocol
• The paper discusses OO considerations deeply
  (Not covered here)
• Difficult to transform all OO extensions for
  distributed protocol like
• ours
• Questions ???