uld be large applications (since code normally on the server is in the client), but Objectivity engineers report that an Objectivity application (with the "server" code linked in) is between 1 and 1.5 megabytes -- not bad in this day and age.
Objectivity applications do require the presence of an Objectivity lock server somewhere on the network. The lock server doesn't perform any real database access. Instead, its job is to provide a centralized resource manager that enforces concurrency throughout the database.
"Database" is an overloaded word in the Ob
jectivity world. What other systems refer to as a database, Objectivity refers to as a
federated database
-- a collection of databases. Functionally, your application can access multiple databases simultaneously, all under control of the single lock manager. These multiple databases make up a
federation
. Most important, all the databases in the federation participate in concurrency controls. The effect is that your application can start a single transaction involving objects from multiple databases, and the coding is no more complex than had you initiated that transaction on a single database.
Objectivity recognizes a variety of "species" of objects. The fundamental storage unit is referred to as a
basic object
. A basic object corresponds to the classes within an application that, by being derived from persistent capable superclasses, can be stored in a database. As with Poet and ObjectStore/PSE, storable basic objects are persistent objects.
Note that some classes that
are not persistent can create objects that are stored in a database as attributes of a persistent class. For example, you can use objects of the
string
class as attributes for persistent classes, and these string objects will be stored with the persistent object. But you cannot use a
string
object to create a persistent object. As it turns out, you don't simply store basic objects directly in a database; you must first place basic objects into a container object (this operation is called
clustering
). A container object acts not only as the storage framework for collections of basic objects, it also serves as the elementary locking unit within an Objectivity/DB database. If you lock an object, you lock the entire container for the object and all other objects within that container.
An application locks a container using one of two access policies: exclusive or multiple readers, one writer (MROW). The former provides strict read or write locking, such that a read lock excludes a
ll write locks, and a write lock excludes all locks. MROW allows unlimited read locks, but only one write lock on the container (thus providing additional concurrency). Hence, you should carefully balance the structure of the overall database in terms of containers versus basic objects. Few containers, with many objects in each container, reduces concurrency because one user's lock on an object in a container locks all other objects within the container from other users. However, having many containers with just a few objects increases overhead in the database.
In addition, containers can be defined as being
garbage-collectible
: Any object within a garbage-collectible container is automatically deleted when all references to that object (from other persistent objects) have been eliminated. The converse of a garbage-collectible container is a nongarbage-collectible container. Objects within this type of container must be explicitly deleted. (Note: Here's where Java shines. Recall that Objectivit
y/DB supports C++ clients. However, C++ clients do not support garbage-collectible objects. The same mechanism that allows Java to garbage-collect transient objects, as part of the way that the language's environment naturally works, gives it the ability to collect persistent objects; no such mechanism exists in C++.)
As with other OO databases, all operations that perform database access must take place within a transaction. Actions on the database are not visible to the "outside world" until the transaction completes. However, modifications to the database are visible to those portions of an application within the transaction. This aspect of a transaction is referred to as
isolation
.
Any access to a persistent object within a transaction proceeds along the following steps. First, the application (with the help of Objectivity methods) creates a local (transient) representation of the object. Next, the persistent object is locked in the database (safeguarding against meddling by other app
lications). This locking is performed for the application on behalf of the Objectivity transaction run-time code. Finally, the actual data is fetched from the database and "poured" into the waiting transient object.
Numerous options are available to enhance an Objectivity database installation. Objectivity/FTO (fault tolerant option) lets you partition a federated database into autonomous pieces so that, if a portion of the database goes down, those pieces still "alive" remain available. With the Objectivity/DRO (data replication option), you can create database "mirror images" for critical applications that cannot endure downtime. If one image goes down, the mirror takes over.
Objectivity adheres to the Object Database Management Group's ODMG-93 standard; the company has added useful extensions, such as indexes and containment iterators. Given that an Objectivity database is accessible from Objectivity "front ends" that can be Java, C++, Smalltalk, or even SQL, Objectivity/DB is a good candidate
if your enterprise's database access must extend across language boundaries.
Where to Find
Objectivity, Inc.
Mountain View, CA
Phone: 650-254-7100
Fax: 650-254-7171
Internet: http://www.objectivity.com
The Federated Database
