13. Configurationdb4o provides a wide range of configuration methods to request special behaviour. For a complete list of all available methods see the API documentation for the com.db4o.config package. A more complete description of Configuration usage and scope can also be obtained from the Reference documentation. Some hints around using configuration calls: 13.1. ScopeConfiguration calls can be issued to a global VM-wide configuration context with
and to an open ObjectContainer/ObjectServer with
A separate configuration instance can be obtained with
or cloned from the global configuration with
Configuration can be submitted when an ObjectContainer/ObjectServer is opened:
Otherwise the global configuration context will be cloned and copied into the newly opened ObjectContainer/ObjectServer. Subsequent calls against the global context with Db4o.configure() have no effect on open ObjectContainers/ObjectServers. 13.2. Calling MethodsMany configuration methods have to be called before an ObjectContainer/ObjectServer is opened and will be ignored if they are called against open ObjectContainers/ObjectServers. Some examples:
Configurations that influence the database file format will have to take place, before a database is created, before the first #openXXX() call. Some examples:
Configuration settings are not stored in db4o database files. Accordingly the same configuration has to be submitted every time an ObjectContainer/ObjectServer is opened. For using db4o in client/server mode it is recommended to use the same configuration on the server and on the client. To set this up nicely it makes sense to create one application class with one method that creates an appropriate configuration and to deploy this class both to the server and to all clients. |