Concurrency and Transaction Management in an Object

Download Report

Transcript Concurrency and Transaction Management in an Object

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



Relational DB

Data is a collection of objects
whose behavior, state, and
relationships are stored as a
physical entity
Language dependence (OOLanguage Specific)
No impedance mismatch in
application using OODB
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

6Obasanjo,





Manifesto
Dare, An Exploration of Object Oriented Database
Management Systems
McClure, Steve, Object Database vs. Object-Relational
Databases, International Data Corporation
Questions?