1. ObjectStore Database System By C. Lamb, G Landis, J.Orenstein, L. Weinreb Presentation by Meghana Chemburkar December 4, 2002 Instructor: Dr.Vasilis Megalooikonomou

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

3. 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.

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

5. Application Interface In addition to data definition and manipulation facilities provided by the host language,ObjectStore provides support for: 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.

6. Accessing Persistent Data #include main(){ //Declare database and an “entry point”into the database of type “pointer to dept.” database *db; persistent department* engineering_department; //Open database db = database::open(“/company/records”); //Start transaction so that database can be accessed transaction::begin(); //The next 3 statements create and manipulate persistent object representing a person named Fred employee *emp = new(db) employee(“Fred”); engineering_department -> add_employee(emp); emp->salary=1000; //Commit all changes to database transaction::commit(); }

7. ObjectStore Collections /*file records.H */ class employee{ public: char* name; int salary; }; class department{ public: os_Set employees; void add_employee(employee *e){ employees->insert(e); } int works_here(employee *e){ return employees->contains(e); }

8. Relationship Facility Relationships can be though of as a pair of inverse pointers,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. object1object2 null

9. Relationship Facility (contd.) /*file records.H */ class employee{ public: string name; int salary; department* dept; inverse_member department::employees; }; class department{ public: os_Set employees; inverse_member employee::dept; void add_employee(employee *e){ employees->insert(e); } int works_here(employee *e){ return employees->contains(e); }

10. 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 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 & overpaid_employee =all_employees[:salary>=100,000:];

11. 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 & work_with_fred = all_employees-> query(‘employee*’,”dept->employees[:name==\’Fred’\:]”);

12. 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.

13. Architecture & Implementation Client-Server Communication Server Client1 Client2 cache

14. Architecture & Implementation (contd.) Cache Coherence The 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 client replies back depending on page’s mode(shared or exclusive).

15. Architecture & Implementation (contd.) Virtual memory mapping Two 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. Relocation When 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.

16. 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.

17. Performance (contd.) Cold Cache is empty cache as would exists when client starts accessing part of database for first time Warm Cache is same cache after a number of iterations have been run. 0 40 60 80 100 20 27 0.7 13 0.1 18 1.2 17 1.2 9484 17 8.4 Time (sec) System oodb1ObjectSotreoodb3oodb4rdbms1index Warm & cold cache traversal results Cold Cache Warm Cache

18. Conclusions ObjectStore gives the users of its target applications 1.High productivity through ease of use. 2.Tight integration with the host language. 3.High performance. Features under development 1.Schema evaluation 2.Communication with existing databases.

19. Questions