Concurrency and Transaction

Management in an Object
Oriented Database

Initial Presentation
Author: 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 Open Source
 FastObjects  Ozone

(formerly Poet)  XL2

 GemStone  FramerD

 Versant  Zope

 Ontos

 Objectivity/DB
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.
 2
Zand et al, A Survey of Current Object-Oriented
Databases, ACM Press, 1995
 3
Thomasian, Alexander, Concurrency Control: Methods,
Performance, and Analysis, ACM Computing Surveys,
1998
 4
Elmasri, R., and Navathe, S, Fundamentals of Database
Systems, Addison-Wesley, 2000.
 5
Atkinson, et al,
The Object-Oriented Database System Manifesto
 6
Obasanjo, Dare,
An Exploration of Object Oriented Database Management Sys
 McClure, Steve,
Object Database vs. Object-Relational Databases,
International Data Corporation
Questions?