An OODBMS from the C++ world takes the natural plunge into Java.
Rick Grehan
Thanks to an ability to quickly store and retrieve complex objects, object databases are well suited for Web-oriented applications. Several object-oriented databases and persistent-object storage systems have appeared for Java, and this column marks the beginning of a series of reviews of them.
A few years ago, I reviewed Poet, a promising C++-based object-oriented database from a company of the same name (see "Poet in Motion," May 1994 BYTE). Its latest product is the Poet 5.0 Object Server Suite, which includes an object server; Software Development Kits (SDKs) for Acti
veX, Java, and C++; Web Factory; and SQL Object Factory. The object server is language-independent -- it merely manages req
uests from a Poet application, which could be written in ActiveX, C++, or Java (which means that a given installation could involve applications written in either language "talking" to the same server).
The server includes facilities to handle administrative chores such as database management, back up and restore, user- access management, and so on. The SDKs are where you build Poet applications. They automate compiles and links, and also let you go through the contents of a database,
viewing
object structures as well as object data. Web Factory lets your application generate Web pages dynamically, and SQL Object Factory lets you program using the Poet API and transparently access data in a Poet or relational database or both. In this article, I focus on the Poet 5.0 Java SDK and server.
A Poet database consists of two or
three storage areas (each storage area becomes a file on the disk). The first is the dictionary, which carries the class-structure definitions for objects in the database. The second area -- the real database -- holds the persistent objects themselves. These two areas work in concert. The database server must have the dictionary to understand the structure of the objects stored in the database. Finally, a database may have one or more indexes associated with it. These are kept in a third area.
Because the structure information for the persistent objects is kept in the dictionary, modifying the dictionary after you have stored data is problematic. How does the system know how to read an object if its structure definition has been altered? Suppose, for example, after you have stored several objects in a database, you alter the class definition for those objects (in the dictionary) to add or remove a member. Poet handles this situation by maintaining multiple class versions in the dictionary.
In oth
er words, Poet knows how to read the "old" objects as well as the "new" ones. Furthermore, when your application reads an old object, Poet automatically converts it to the new format. When you save that old object into the database, its structure is automatically updated.
Poet is compliant with release 2.0 of a standard from the Object Database Management Group (ODMG) that helps ensure the portability of databased applications across platforms and products. This compliance means a great many things, including the fact that Poet supports embedded and ad hoc queries in the object query language (OQL). I invite you to visit the Poet Web site (
http://www.poet.com
) for details. An important part of ODMG compliance is that Poet uses
persistence by reachability
. That means that object A becomes persistent if it i
s referenced by persistent object B.
For concurrency and integrity management, Poet supports powerful transaction capabilities. Transactions can be nested, which allows you to create
commit levels
. This allows you to create a situation in which an enclosing transaction commits only if all its component transactions were successful. If one of the enclosed transactions failed, the application can abort the outer transaction and return the database to its previous consistent state. You can build more elaborate transactions using the checkpoint feature.
A checkpoint acts as a kind of internal commit. In other words, if, in the midst of a transaction, an application issues a checkpoint call, all modifications to that point are committed. This is useful when a transaction involves large amounts of data and a single final commit would result in a storm of I/O to the database. Internal checkpoints let you throttle the flow of data into the database.
Locks in the Poet system can be either impl
icit or explicit. Implicit locks are automatically placed on objects that your application reads or modifies in the database. Explicit locks come in four flavors: read, update, write, and delete. Each has its own interaction characteristics.
For example, a read lock lets other database users only read the locked object (they cannot modify or delete the object). Similarly, a delete lock assures that no other user attempts to read or modify the locked object. For finer locking control, the underlying Poet engine recognizes up to six lock levels. Your application can apply these lock levels if the four standard lock levels are for some reason insufficient.
The Poet 5.0 Java SDK is available for Windows 95 or NT for $1500 (Poet sells each SDK separately). I tested the NT version, which was in the early stages of release (the manual was available only in Acrobat Reader format). Still, if the final product is as good as its C++ ancestor, Poet should be a powerful, easy-to-use persistent-object storage s
ystem worth your consideration.
Product Information
Object server.................$5000 NT version
Java SDK......................$1500
Run-time client...............$ 140 each
SQL Object Factory..........$10,000
Web Factory...................$1500
Poet Software
San Mateo, CA
Phone: 800-950-8845
Phone: 650-286-4640
Fax: 650-286-4630
E-mail:
info@poet.com
Internet:
http://www.poet.com
Enter 1074 on Inquiry Card.
Information on
this product
and similar products (data managem
ent)
HotBYTEs
- information on products covered or advertised in BYTE
screen_link (38 Kbytes)
Poet's database browser looks much like an object browser. You can visually navigate through the classes and objects in a database.
Rick Grehan is a senior editor at Computer Design magazine and coauthor of The Client/Server Toolkit (NobleNet, 1996). You can contact him at
rickg@pennwell.com
.
Poet Goes Java
