This post originated from an RSS feed registered with Java Buzz by Weiqi Gao. Original Post: eXtremeDB eXposed Feed Title: Weiqi Gao's Weblog Feed URL: http://www.weiqigao.com/blog/rss.xml Feed Description: Sharing My Experience... Latest Java Buzz Posts Latest Java Buzz Posts by Weiqi Gao Latest Posts From Weiqi Gao's Weblog

OK. Today's OCI C++ lunch features Rob Martin talking about McObject's eXtremeDB embedded database product.

First person is Rob now.

We evaluated this product because a key customer wanted to use a embedded database as the foundation for their next generation products. eXtremeDB won the evaluation.

It is a memory resident database; can be put in the process space, or in shared memory. If you put it in heap, there is a feature that allows you to persist the data.

Performance of this thing is extremely good. Transactions incur low overhead.

It is a commercial product.

We found it to be fairly reliable. We did hit some problems. But they are all resolved by either us understanding the product better, or by McObject acknowledges them as bugs and subsequently fixed.

Small foot print, not heavy weight.

Times Ten, a competitor of eXtremeDB was bought by Oracle.

They have a DDL and a schema compiler. It supports structs, including nested structs. But a structure needs to be inside a class for instantiation.

Ways to identify objects in the database: oid (database wide), autoid (system generated serial number), ref (embedded reference to an entity's oid.)

Standard CRUD. Finders. Lookup by hash. Lookup by tree index (unique as well as non-unique.)

Transactions are simple: read, write, commit, rollback. Transactions are database scoped. You can change it through build time switches, but for our usage scenarios, database wide locking turns out to be optimal.

Kevin, our resident eXtremeDB expert, chimed in: "you have to understand how fast their transactions is. They are in microseconds."

There is also a limit on the number of entities that you can touch within a transaction.

Supports persistence which is essentially transactions logging. It depends on the OS file system. On recovery, one "sync"s the disk image with the memory image.

eXtremeDB claims to have object semantics. But the content is rich structure types. The primary interface is structured procedure calls. There is a thin object wrapper that is generated from the DDL. It feels more relational to me than object based.

The company (McObject) is in Seattle with a group in Washington, DC. They do their thing through memory management and aggressive locking strategies tailored to the app. They avoid heap allocation of memory in the engine.

We felt very comfortable with this database. We didn't do much C++ structures in our code and uses eXtremeDB extensively.

Their support staff is very responsive. The turn around time is usually within 24 hours. All of our support requests have been resolved. We did find out one bug regarding a clever bit of threading code (transaction without mutex) that only manifests itself on dual CPU machines running Windows and that one took two or three rounds.

OCI and McObject are partners of each other now.

Their DDL supports: signed, unsigned char (64K limit) enum, struct (only fixed size structs can be oids), autoid_t, blog, data, ref, string, time, vector.

And here's an example:

declare database eeDemo;
declare oid personId[1024];

compact class Location {
  string streetAddress;
  string city;
  string state;
  string zipcode;
  autoid[4096];

  tree byZipCode;
};

compact class Person {
  oid;
  autoid_t home;
  autoid_t work;
  autoid_t temp;
};

We added MPC support for compiling the eXtremeDB schema. We don't run it by hand.

The generated code are C and C++ header and implementation files. The generated C code will have functions for Person_home_get() and Person_home_put(). The generated C++ code will have a Person class that has home_get() and home_put() methods.

Search methods and comparison methods are generated. Cursor manipulation code for using any tree index is also generated. A checkpoint() method is generated to update hash indexes after entity manipulation.

The client code looks like this:

mco_error_set_handler(onError);
start();
uint4 dbSize = (1 * 1024 * 1024);
uint2 pageSize = 4096;
void * heap = malloc(dbSize);
mco_db_open("eeDemo");
mco_db_h dbHandle;
connect(dbName, &dbHandle);
mco_trans_h txn;
startWriteTxn(&dbHandle, &txn);
rollback(&txn);
startReadTxn(&dbHandle, &txn);

{
  mco_trans_h txn2;
  startReadTxn(&dbHandle, &txn2);
  commit(&txn2);
}

disconnect(&dbHandle);
closeDB("eeDemo");
stop();

We wrote a set of wrappers that made using eXtremeDB very handy, including a DB registry, Transaction, TransGuard, ReadTransGuard, WriteTransGuard, WriteTransGuardProxy. The various trans guards uses the C++ guard concept to make database code dead easy.

The eXtremeDB product has some features, such as SQL and events, that we did not use.

Rob is done. First person is Weiqi now.

Until next time.