A Multi-Granularity Locking Model

A Multi-Granularity Locking Model For Concurrency Control in OODBMS Suh-Yin Lee & Ruey-Long Liou Nirmit Desai

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

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…. Nirmit Desai

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

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

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

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 !! Nirmit Desai

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) Nirmit Desai

Compatibility Matrix • N means not compatible, Blank means comp[atible Nirmit Desai

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 what’s left ? We seem to be able to do everything now… • OODBMS has many other conflicting properties which need special handling Nirmit Desai

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!! Nirmit Desai

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; } Nirmit Desai

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 ? Nirmit Desai

Conflicts in OODB • Instance-Instance conflict • Instance-Schema conflict • Schema-Schema conflict Class Level Vehicle CompositeClass make Owner car xyz ID name SSN Instance Level c1 c2 c3 Nirmit Desai

ORION Locking Model • Instances (Objects): S and X modes • Classes (Schemas): S, X, IS, IX and SIX modes Nirmit Desai

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 Nirmit Desai

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 composite2 composite1 S car1 owner1 car2 ISO Vehicle Owner ISOS Nirmit Desai

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 Nirmit Desai

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) Nirmit Desai

Summary • OODBMS brings its own problems for concurrency • ORION model takes care of composition • It can be improved greatly • It’s 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 ??? Nirmit Desai

A Multi-Granularity Locking Model