Path: news.daimi.aau.dk!jlk From: jlk@daimi.aau.dk (J|rgen Lindskov Knudsen) Newsgroups: comp.lang.beta Subject: Re: OODBMS Date: 26 Jan 1995 22:20:11 GMT Organization: DAIMI, Computer Science Dept. at Aarhus University Lines: 150 Message-ID: <3g976r$c0b@belfort.daimi.aau.dk> References: <3fl618$p6g@fbi-news.informatik.uni-dortmund.de> Reply-To: jlknudsen@daimi.aau.dk (Jorgen Lindskov Knudsen) NNTP-Posting-Host: lithium.daimi.aau.dk In <3fl618$p6g@fbi-news.informatik.uni-dortmund.de> Thus spake knaut@esche.informatik.uni-dortmund.de (Claus-Peter Knaut (pg258)): >Hello, >Can somebody tell me about the OODMBS of BETA. We could use it in out >project for >a probabilistic DBMS. >If it runs we would not have to programm the operations on relations. >Thanks Please find enclosed a short descripton of the OODB for BETA (pre-release). ------------------------------------------------------------------------------- Distributed Object-Oriented Database for BETA --------------------------------------------- The Distributed Object-Oriented Database (OODB) is a persistent store for BETA objects. Persistence is fully transparent, since all BETA objects may be stored in the OODB. The data-definition language for the OODB is the BETA programming language, i.e. it is not necessary to use a separate language for data-definition. The distributed Object-Oriented Database for BETA is available for alpha-testing. Ask for details. 1. Working components 1.1 Transitive closures of complex object structures. In the OODB the burden of storing complex structures is moved away from the database application and into the database itself by providing general operations able to put and get arbitrary data structures from secondary storage. One operation stores an object including its transitive closure, i.e., all objects reachable through references (pointers) are also stored in the OODB. Another operation provides fetching an object including its transitive closure. The fetch of objects is lazy since the OODB will only move objects into memory when they are accessed. 1.2 Notification handling To support asynchronous cooperative work, facilities for notification handling make a client able to be notified about changes made by other clients. The lock management on the persistent objects follows a simple read-write conflict scheme. Combined with the notification mechanism clients are able to dynamically exchange write locks on objects. 1.3 Parallel transactions Working in a cooperative setting a client often works on different tasks simultaneously. The OODB supports grouping updates together according to these tasks and committing or aborting all changes belonging to one specific task at a time. Such a group of updates forms a transaction. A client may have multiple transactions going on in parallel. 1.4 Persistent shared containers In general, containers like lists and hashtables may contain very large sets of objects. Maintaining copies of such structures by clients is very expensive regarding time and memory. To address this issue a new container type called the shared container has been introduced. Every instance of a shared container exists only in one version, physically located on an OODB server. A client is restricted to access the container remotely via an interface resembling the interfaces to containers in BETA's standard library. 3. Future components Facilities for version management and schema evolution is currenly being developed. 3.1 Object browser library An object browser library will be provided to offer browsing facilities concerning objects pertaining to an application. The object browser library will be able to display an object and all objects referenced by it. The unfolding of object references will be fully controlled by the user of the application. 4. Example of use The OODB has been developed in parallel with the Devise Hypermedia (DHM) Framework. The hypermedia uses the OODB when (parts of) a hypermedia is stored persistently. A hypermedia network usually has a complex structure, which cannot be predicted in that the end-users may link data exactly the way they want to. The OODB enables the application programmer to store and fetch complex hypermedia structures by simply passing a reference. In addition, hypermedia clients may subscribe to notifications from other clients accessing the same objects. A client may, for example, be notified when a new version of an object is stored. Finally, a hypermedia contains a list of all its components modelled as a shared container. This enables the hypermedia to centrally maintain a single component list on the server, instead of each client maintaining its own copy. In general, DHM represents a typical example of a "new generation database application" and, thus, the needs of the hypermedia have had (and still has) a major influence on the design of the OODB. 5. Implementation The OODB is based on a distributed client-server architecture on heterogenous systems. A client is able to connect to multiple databases on one or more servers on different machines. A server is able to serve multiple databases simultaneously. Additionally, support for object references between objects stored in different databases is about to be introduced. The communication between servers and clients is fully symmetric. It allows not only the client to contact the server, but also the server to notify clients about changes to stored data. The communication is realized using the general and flexible distribution mechanism provided by the Mjolner BETA environment. In the current version clients and servers may run on UNIX work-stations (Sun and HP). In a future release, support for Macintosh and Intel486-based PCs running Linux or Windows NT or Windows 95 will be included. For example, a server may run on a Unix work station while clients are running on any of the supported platforms. 6. More information A preliminary manual is available in PostScript format. Send an e-mail to: les@daimi.aau.dk and we will send you a copy of this manual. Questions, etc. about the OODB and the aplha program can also be obtained by sending an e-mail to: les@daimi.aau.dk -- Jorgen Lindskov Knudsen, Computer Science Department, Aarhus University Ny Munkegade 116, DK-8000 Aarhus C, DENMARK E-mail: jlknudsen@daimi.aau.dk, Phone: +45 89 42 32 33, Fax: +45 89 42 32 55