A MultiGranularity Locking Model For Concurrency Control in

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: “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 Table Tuples

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

The Track • Multi-Granularity (Background) • General Locking Model (DBMS) • OODBMS Considerations (Topic of the Paper) • ORION Locking Model • Comparison • Summary 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

The Track • Multi-Granularity (Background) • General Locking Model (DBMS) • OODBMS Considerations (Topic of the Paper) • ORION Locking Model • Comparison • Summary 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 Composite. Class { Vehicle car; Owner xyz; } Class Vehicle { int make; int ID; } Class Owner { char *name; char *SSN; } main() { Composite. Class c 1, c 2; Vehicle car 1, car 2; } 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 Vehicle make ID Class Level Composite. Class car xyz Owner name SSN Instance Level c 1 c 2 Nirmit Desai c 3

The Track • Multi-Granularity (Background) • General Locking Model (DBMS) • OODBMS Considerations (Topic of the Paper) • ORION Locking Model • Comparison • Summary 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 composite 1 car 1 composite 2 owner 1 car 2 • Owner owner 1 has two Cars: car 1 and car 2 • owner 1 is a shared reference between composite 1 and composite 2 • car and car 2 are exclusive references Nirmit Desai

An Example • Read composite 1 instance of Composite. Class - lock Composite. Class in IS mode - lock composite 1 in S mode - lock Vehicle class in ISO mode - lock Owner class in ISOS mode Composite. Class composite 2 car 1 Vehicle owner 1 composite 1 car 2 Owner Nirmit Desai

Observations • owner 1 and car 1 were never locked - This restricts the degree of concurrency • Redundancy in the compatibility matrix - This increases the number of modes unnecessarily Nirmit Desai

Observations • owner 1 and car 1 were never locked - This restricts the degree of concurrency • Redundancy in the compatibility matrix - This increases the number of modes unnecessarily Nirmit Desai

Observations • owner 1 and car 1 were never locked - This restricts the degree of concurrency • Redundancy in the compatibility matrix - This increases the number of modes unnecessarily Nirmit Desai

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

Comparison (Our protocol) • Read composite 1 instance of Composite. Class - lock Composite. Class in IS mode - lock Vehicle class in IS mode - lock Owner class in IS mode - lock composite 1 in S mode - lock car 1 in S mode - lock owner 1 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