JPOX supports 2 modes of operation of db4o - file-based, and client-server based. In order to do so and to fit in with the JDO/JPA APIs we have defined the following means of connection.

The following JDO connection properties will connect to a local file-based DB4O running on your local machine

javax.jdo.option.ConnectionURL=db4o:file:/{my_db4o_file}

The following JDO connection properties will connect as a client to a DB4O server

javax.jdo.option.ConnectionURL=db4o:{db4o_host}:{db4o_port}
javax.jdo.option.ConnectionUserName=
javax.jdo.option.ConnectionPassword=

DB4O doesn't itself use such URLs so it was necessary to define this JPOX-specific way of addressing DB4O.

When persisting objects to DB4O, the PersistenceManager will assign a StateManager to the object and call "makePersistent" on the StateManager. This in turn calls DB4OManager.insert(). The process here is very simple. A PersistFieldManager will check through all fields of the object to persist and if any are PersistenceCapable will try to persist them too. This in turn assigns StateManagers to these objects and the DB4OManager.insert() is called again. This means that, for a transaction, the DB4OManager.insert() builds up a list of objects to persist in its insert process, and when all dependent objects are processed (assigned StateManagers and called DB4OManager.insert) will then do the actual persistence for the original object. This will persist all objects in the object graph (DB4O provides this).

After the use of DB4O's ObjectContainer.set() to persist the object graph any datastore identities are assigned (using DB4O's internal id as basis), and any versions are retrieved for those objects that require version handling.

After persistence of the objects all mutable SCO fields are replaced with their wrapper types. This is done after persistence so that we dont store SCO types in DB4O (which would work, but is easier to handle elsewhere if we only have real JDK types stored).

When a user calls a method like PersistenceManager.getObjectById() a call will be passed to DB4OManager.fetch() and this retrieves an object (and its object graph, down to DB4O's fetch depth). Before handing these objects back to the user the graph is traversed and StateManagers assigned to all objects (in lifecycle state PERSISTENT CLEAN). Any fields that have an object that is not "activated" by DB4O (due to being at the edge of DB4O's object graph) will be set as not loaded with the intention of loading it when/if it is accessed later.

Object retrieval using JDOQL is discussed in detail here