 |
 |
        
|
|
|
|
|
|
|
|
datanucleus-db4o provides persistence of Java objects to DB4O datastores. It builds on top of the basic persistence provided by datanucleus-core This plugin was part of AccessPlatform upto and including 3.0 and is no longer developed
datanucleus-db4o is downloadable as following
datanucleus-db4o is dependent on the following packages of software. Click on the name to go to the home page for that software to download it.
| Package | Version | Description | Required? |
|---|---|---|---|
| datanucleus-core | 3.0+ | Provides logging, localisation, and other framework facilities for DataNucleus | Yes |
| DB4O | 7.0+ | DB4O Datastore | Yes |
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 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.