The API
Listing 1 is a simple example illustrating how to create, store, modify, and finally delete a Customer object. Developers familiar with EJB 3/JPA (the Java Persistence API) or Hibernate shouldn't have a problem adapting.

In db4o, an object container is initially created. This is an object analog to the JPA/Entity Manager responsible for object administration.

The JPA/Entity Manager, however, gets its environment from a configuration of diverse factories and, if applicable, even from the Spring Bean repository. In db4o, only one file or server (via TCP/IP) has to be named.

In the first case, db4o uses just one proprietary file. This makes db4o the ideal choice for mobile devices. But the exchange of db4o database files, for example, by e-mail, is also a benefit that many companies appreciate even though the data isn't available in an independent format.

With the ObjectContainer, the user has implicitly opened a transaction. That's why there's no need for a call like entityManager.getTransaction() in Hibernate or JPA.

Taking the notion of CRUD functionality, we notice many differences but also similarities.

• db.set() stores an object. In JPA this equals em.persist(...). In an ActiveRecord environment like Ruby on Rails, creating an object would be sufficient to persist it.
• db.delete() deletes an object, analogous to em.remove() in JPA.
• In JPA, one would update modified objects with em.merge(...). In db4o this is done simply by modifying and storing the object with set(). In this case it's necessary for the object to be found via a previous query; a "weak reference" between the object and the ObjectContainer will have been established. So an update command isn't necessary. In JPA, the object just needs to be attached, which can be done with em.refresh().

The commands (not, however, the ideas and approaches) for retrieving objects also differ slightly and will be examined later on.

Object Management
Without a doubt the biggest benefit of object databases such as db4o is that all objects can be stored just the way they are.

The Customer object stored in Listing 1 could just as easily be extremely complex:

• It could be at the end of a long inheritance hierarchy
• It could contain many sub-objects that in turn can be as deep as required

In industry applications, object depths of 10 to 20 aren't unusual. In object databases, all objects can be stored instantly just the way they are. All objects can be stored type-independent (type-orthogonal). Complex collections and the deep object structures mentioned above aren't a problem at all. The code or the domain objects don't need modification. There's no need for "implements," bytecode enhancements, or annotations.

Using OR-mappers is a lot more complex. The mapping of deep objects and especially the management of schema changes is much more time-consuming. Nevertheless JPA or Hibernate 3.2 already have a strong implementation and are well on their way to improving their ease of use. The annotation of classes with Java annotations (e.g., @Entity) strongly reduces time and effort. This used to be very difficult in big projects with deep XML classes.

Only the notation of JPA relations (@one-to-one, @one-to-many, @many-to-many), the bi-directionality, and the special cases (e.g., the database differs from the object schema) are still a little annoying.

When storing, updating, and loading objects in db4o or JPA/EJB/Hibernate, one previously had to consider similar aspects: Up to what object depth are objects to be stored, updated, or activated? What is the default depth? In db4o all this can be adjusted with just a single line of code. Sub-objects that aren't active can also be activated with activate().

In versions 6.2 and 6.3, db4o introduced transparent activation (TA). With TA, objects are only retrieved when requested. Initially sub-objects aren't retrieved. In case these sub-objects are required, db4o will automatically activate and retrieve them.

This isn't as fast as manual activation but in exchange the application developer doesn't need to worry about update levels.

Transactions
As shown in Listing 1, the ObjectContainer implicitly starts a transaction. This transaction can be completed or undone with commit() or rollback(). Actions in the transaction or single commands are always ACID in db4o. In db4o this is achieved by quasi-serialising all operations. As a result db4o is extremely transaction-safe but on the other hand inappropriate for multithreaded access. A Web application with dozens of database queries a second isn't as easily realizable as other replicated and highly scalable database architectures (e.g., as in Oracle/DB2) even if single-threaded access is extremely fast.

db4o has only implemented read-committed access mode. Switching to a different isolation level isn't possible.

Query Languages
The most interesting analysis might be the comparison of query languages. Even here db4o, EJB, JPA, and Hibernate resemble each other more than one might think.

Depending on db4o's implementation, queries are either executed in the application itself or in the db4o server instance.

Let's go through the requirements step-by-step: