Concurrency and Transaction Management in an Object Oriented Database

Initial PresentationAuthor: Jeremy Torres

Date: 5/30/2003

Agenda Brief introduction to Object Oriented

Database Definitions required for the discussion of

concurrency and transaction management

Desired properties of a database management system

Research Goals and Objectives Work Plan Q and A

An Object Oriented Database…

Is the coupling of Object Oriented (OOP) Programming principles with Database Management System (DBMS) principles

Provides access to persisted objects using the same OO-programming language

OODB and Relational DB

Differences2,6

OODB Uses an OO data model

Data is a collection of objects whose behavior, state, and relationships are stored as a physical entity

Language dependence (OO-Language Specific)

No impedance mismatch in application using OODB

Relational DB Uses record-oriented

model Data is a collection of

record types (relations), each having collection of records or tuples stored in a file

Language independence (via SQL)

Impedance mismatch in an OO application. Mapping must be performed

Some OODBMS’s

Commercial FastObjects

(formerly Poet) GemStone Versant Ontos Objectivity/DB

Open Source Ozone XL2 FramerD Zope

Academic ObjectStore

Definitions4 1 of 3 Data Items—collection of objects representing

a database Granularity—size of a data item Concurrency—multiple users accessing a

database instance at the same time Transaction—a logical unit of database

processing that includes one or more database access operations

Insert, Delete, Modify, Retrieve operations Serializability—Interleaving execution of a set

of concurrent transactions without “giving up any correctness”

Definitions, 2 of 3

Concurrency Control Protocols—set of rules for defining the execution of concurrent transactions (ultimately to ensure serializability) Optimistic Concurrency Control—

validation or certification of a transaction AFTER it executes

If interference is detected, the transaction is aborted and restarted at a later time

Definitions, 3 of 3 Pessimistic Concurrency Control—Locks

are used to prevent conflicting transactions

2-Phase Locking Protocol (2PL): Best known locking protocol for guaranteeing serializability

Phase 1: Expanding/Growing. New locks can be acquired but none can be released

Phase 2: Shrinking. Existing locks can be released but no new locks can be acquired

Strict 2PL—a transaction does not release any of its exclusive (write) locks until after it commits or aborts

Database Management Systems Should…1 of 2 Provide Concurrency Control4

The DBMS should allow more than one user to access/manipulate data concurrently

When there is concurrency, Transaction Management must be addressed

The Lost Update Problem—two transactions have their operations interleaved in such a way that some database item is incorrect—inconsistent state!

The Temporary Update (Dirty Read) Problem—One transaction updates a database item and then the transaction fails; the updated item is access by another transaction before it is changed back to its original value

Database Management Systems Should…2 of 2 Provide Transactions that have ACID

properties4: Atomicity—a transaction is an atomic unit of work;

it’s performed in its entirety or not at all Consistency preservation—a transaction takes

database from one consistent state to another Isolation—a transaction should appear as though it is

being executed in isolation from other transactions Durability or permanency—the changes applied to

the database by a committed transaction must persist in the database. The changes must not be lost because of any failure

Concurrency and Transaction Management: OODBM’s vs. RDBM’s

Both DBMS’s must deal with Concurrency and Transaction Management issues

Many concurrency protocols can be applied to both DBMS’s Optimistic and Pessimistic protocols are

relevant to both However, semantically different:

Example: Data Item Granularity In traditional RDBMS, fine granularity data item

would be a record field value of a record In an OODBMS, fine granularity data item may be

an Object or data member (field) of an Object

Many OODB’s…Varying Frameworks There are many OODBM’s existing and emerging in both

commercial and open source areas Implementations vary differently

Distributed database model Centralized database model “hybrid” implementation, such as Object-Relational

Databases Use Relational DBMS Engine Use Structured Query Language (SQL) or an extension of it for

providing access to “Objects” Currently, there is no consensus or clear specification

for an OODMS as there was for a Relational DBMS (such as Codd’s original specification for a relational data model and query language)5

NOTE: The Object Data Management Group (ODMG) has a specification for portability; however, ODMG-specific object models and query languages are used.

Study Rationale My research has not found a generic,

reusable design pattern for a transactional engine, or “layer”, geared specifically toward object oriented databases. 

Even though there are many varying implementations of object oriented databases, there are very few research papers (as found in the initial research phase) describing an complete transactional engine implementation

Research Objectives/Goals To design a flexible and extendable

(“pluggable”) framework for concurrency and transaction management within the context of an object oriented database using the Java programming language

Ideally, the framework will be presented as a design pattern specifically for concurrency and transaction management of an Object Oriented database

Research Objectives/Goals Cont’d

Provide various implementations of the framework, each providing different transactional properties (e.g., optimistic versus pessimistic locking), for the ObjectStore

Research Design The generic framework proposed, designed,

and implemented by this research will be compared against the strengths and weaknesses of other alternative implementations (e.g., the Gemstone and Ozone object oriented databases) found during the research process

The comparison will focus on the design and implementation of the concurrency and transactional software “layers” of an object oriented database only; the remaining “layers” are out of the scope of this research

ObjectStore Project Current State

The ObjectStore Object Oriented Database is geared specifically for Java

Does not contain transaction management

Accessible by remote clients via RMI

High-Level Logical Diagram

Issues To Be Addressed

Object Store is distributed via Java RMI The framework proposed will have to

account for each client’s state

Work Plan Phase I: First Presentation, May 30th, 2003: The

research for this first phase will be completed. Phase II: Summer I and II, 2003: Development and

implementation of generic Concurrency/Transactional Model via the ObjectStore will be completed

Phase III: Second Presentation, September 2003. Results of developed concurrency model and implementations via the object store presented.

Completion: Final Presentation, November 2003. Demonstration of implemented framework via ObjectStore. All results of framework and implementations, including changes since second presentation.

References Maier et al, Development of an Object-Oriented DBMS,

ACM Press, 1986. 2Zand et al, A Survey of Current Object-Oriented

Databases, ACM Press, 1995 3Thomasian, Alexander, Concurrency Control: Methods,

Performance, and Analysis, ACM Computing Surveys, 1998

4Elmasri, R., and Navathe, S, Fundamentals of Database Systems, Addison-Wesley, 2000.

5Atkinson, et al, The Object-Oriented Database System Manifesto

6Obasanjo, Dare, An Exploration of Object Oriented Database Management Systems

McClure, Steve, Object Database vs. Object-Relational Databases, International Data Corporation

Questions?