|
DataNucleus started providing persistence to DB4O datastores in the JPOX 1.2 release cycle. When
persisting to RDBMS datastores DataNucleus had to perform significant work to provide persistence
of objects due to provision of O/R mapping. With DB4O it is all much simpler.
DataNucleus supports 3 modes of operation of
db4o
- file-based, and embedded server based
and client-server based. That is
-
db4o:file:{filename}
-
db4o:server:{filename}
-
db4o:{host}:{port}
DB4O doesn't itself use such URLs so it was necessary to define this DataNucleus-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.
|
|
