ObjectStore Database System By

C. Lamb, G Landis, J.Orenstein, L. Weinreb

Presentation byMeghana Chemburkar

December 4, 2002

Instructor: Dr.Vasilis Megalooikonomou

Overview

Introduction Integration with C++ Application Interface Architecture & Implementation Performance Conclusions

Introduction

ObjectStore is an Object Oriented database management system(OODBMS) that provides a tightly integrated language interface to the traditional DBMS features of persistent storage,transaction management,distributed data access.

It was designed to provide a unified programmatic interface to both persistently allocated data and transiently allocated data,with object-access speed for persistent data usually equal to that of in-memory deference of a pointer to transient data.

Target applications are programs like CAD,CAE, GIS(Geographic Information System) etc that perform complex manipulation on databases of objects with intricate structure.

Integration with C++

ObjectStore is closely integrated with the programminglanguage . C++ was selected as programming languagethrough which OjectStore can be accessed.Reasons: Ease in learning No translation code Reusability

Application Interface

In addition to data definition and manipulation facilitiesprovided by the host language,ObjectStore provides supportfor: Accessing the persistent data inside transactions Library of collection types Bi-directional relationship Optimizing Query Facility Version Facility for collaborative work. Tools supporting database schema design,database

browsing ,database administration,application compilation & debugging etc.

Accessing Persistent Data#include <objectstore/objectstore.H>#include <records.H>main(){//Declare database and an “entry point”into the database of type “pointer to dept.”database *db;persistent<db> department* engineering_department;

//Open databasedb = database::open(“/company/records”);

//Start transaction so that database can be accessedtransaction::begin();

//The next 3 statements create and manipulate persistent object representing a personnamed Fredemployee *emp = new(db) employee(“Fred”);engineering_department -> add_employee(emp);emp->salary=1000;

//Commit all changes to databasetransaction::commit();}

ObjectStore Collections

/*file records.H */

class employee{public:char* name;int salary;};

class department{public:os_Set<employee*> employees;

void add_employee(employee *e){employees->insert(e);

}

int works_here(employee *e){return employees->contains(e);

}

}

Relationship Facility

Relationships can be though of as a pair of inversepointers,so that if one object points to another,the second object has an inverse pointer back to the first.

If one participant in the relation is deleted then the pointer to that object ,from other participant is set to null.

One to one,one-to-many and many-to-many relationships are supported.

object1 object2 object2null

Relationship Facility (contd.)/*file records.H */

class employee{public:string name;int salary;department* dept;inverse_member department::employees;};

class department{public:os_Set<employee*> employees;inverse_member employee::dept;

void add_employee(employee *e){employees->insert(e);

}

int works_here(employee *e){return employees->contains(e);

}}

Associative Queries

ObjectStore queries are closely integrated with host language. A query is simply expression that operates on one or more

collections and produces a collection or reference to an object.

[: :] is ObjectStore syntax for queries. e.g.Suppose all_employee is set of employee objects

os_Set<employee*> all_employees;

The following statement uses query against all_employees to find employees earning over $100,000 and assign the result to overpaid_employees:os_Set<employee*>& overpaid_employee =all_employees[:salary>=100,000:];

Associative Queries (contd.)

The query to find employees who work in the same department as Fred.(using ObjectStore’s compiler)

all_employees[:dept->employees [:name==‘Fred’ :]:];

The above query (using C++ library interface) os_Set<employee*>& work_with_fred = all_employees->

query(‘employee*’,”dept->employees[:name==\’Fred’\:]”);

Versions

ObjectStore provides facilities for multiple users to share data in a cooperative fashion.With these facilities,a user can check out version of the object,make changes and then check changes back in to main development project so that they are visible to other members of team.

Users can control exactly which version to use ,for each object or group of objects by setting up private workspaces that specify the desired version.

Architecture & Implementation

Client-Server Communication

Server

Client1 Client2

cache cache

Architecture & Implementation (contd.)

Cache CoherenceThe page can reside in the client cache without being locked,some other client might modify the page,invalidating the cached copy. The mechanism for making sure that transactions see valid copies of pages is called cache coherence.

Server sends callback message to client and holding clientreplies back depending on page’s mode(shared or exclusive).

Architecture & Implementation (contd.)

Virtual memory mappingTwo independent databases might use same address space for their own objects. Objectstore solves this problem by dynamically assigning potions of address space to correspond to portions of the databases used by application.

RelocationWhen database size exceeds the size of available address space,relocation is done.When the page is mapped into virtual memory,the correspondence of objects and virtual addresses may have changed.The value of each pointer stored in page must be updated to follow the new virtual address of object.

Performance

The Cattell Benchmark was designed to reflect the access pattern of engineering applications.The benchmark consists of several tests,but only transverse tests results are shown since they best illustrate the performance benefits of ObjectStore.

The results with client and server on different machines are shown.The difference between cold and warm cache times shows that client cache and virtual memory mapping has significant performance benefit.

Performance (contd.)

Cold Cache is empty cache as would exists when client startsaccessing part of database for first timeWarm Cache is same cache after a number of iterations have beenrun.

0

40

60

80

100

20

27

0.7

13

0.1

18

1.2

17

1.2

94 84

17

8.4

Time (sec)

System

oodb1 ObjectSotre oodb3 oodb4 rdbms1 index

Warm & cold cache traversal results

Cold Cache

Warm Cache

Conclusions

ObjectStore gives the users of its target applications1.High productivity through ease of use.2.Tight integration with the host language.3.High performance.

Features under development1.Schema evaluation2.Communication with existing databases.

Questions