ObJectRelationalBridge
BRIDGING JAVA OBJECTS AND RELATIONAL DATABASES


the ojb properties file

Author: Thomas Mahler, september 2001

ojb configuration

OJB provides two different configuration mechanisms:

  1. A XML based repository is used to define the Object/Relational Mapping. This Mapping is translated into a metadata layer at runtime. The metadata layer may be manipulated at runtime through OJB API calls. Follow this link to learn more about the XML repository

  2. A properties file OJB.properties that is responsible for the configuration of the OJB runtime environment. It contains information that is only needed at startup and is not expected to change at runtime or to be O/R mapping related. Have a look at the default version of this file.

By default this file is named "OJB.properties" and is loaded from the working directory (i.e. The directory from where the JVM is started). The filename of the properties file can be changed by setting a runtime switch to the JVM:

java -DOJB.properties=myOwnPropertiesFile.props my.own.ojb.Application.

The rest of this document describes the things that can be set through the OJB.properties file.

settings in the properties file

entry

meaning

repositoryFile

The repositoryFile entry tells OJB to use this file as its standard O/R mapping repository. If no path is specified the file is looked up in the working directory from that OJB was started.

ConnectionFactoryClass

The ConnectionFactoryClass entry determines which kind of ConnectionFactory is to be used within OJB. A ConnectionFactory is responsible for creating JDBC Connections. The default implementation uses the java.sql.DriverManager to obtain connections. In J2EE container environments it may be more appro to use a Datasources based Factory. OJB provides a ConnectioFactoryJNDIImpl that uses Datasources looked up from the JNDI initial context to obtain Connections.
The class set in this entry must implement the interface ojb.broker.accesslayer.ConnectionFactory.

SequenceManagerClass

The SequenceManagerClass entry determines the SequenceManager to be used. The default implementation is not very elaborated. This entry allows to plugin better versions. Follow this link to learn more about the OJB SequenceManager.
The class set in this entry must implement the interface ojb.broker.util.SequenceManager.

SequenceManagerGrabSize

The SequenceManagerGrabSize entry determines the number IDs allocated within each sequence. This parameter is useful only if you use the ojb.broker.util.SequenceManagerHighLowImpl.

SequenceManagerGlobalIDs

Specifies wether IDs should be unique for each id-name (so IDs would be unique over all classes that use "oid" for their id and unique over all classes that use "articleID" for their id, but not for the union of those (so there could be an oid 4 and an articleID 4). This mode interacts very badly with legacy data, as it doesn't try to find the highest used ID over all classes, but only for those that are first accessed. This parameter is useful only if you use the ojb.broker.util.SequenceManagerHighLowImpl.

ObjectCacheClass

The ObjectCacheClass entry tells OJB which Cache implementation is to be used. OJB provides several pluggable Cache implementations in package ojb.broker.cache.
Follow this link to learn more about the OJB ObjectCache.
The class set in this entry must implement the interface ojb.broker.cache.ObjectCache.

LockManagerClass

The LockManagerClass entry tells OJB which concrete LockManager implementation is to be used.
The class set in this entry must implement the interface ojb.odmg.locking.LockManager.
Follow this link to learn more about the OJB LockManager.

LockTimeout

The LockTimeout entry defines the maximum time in milliseconds that a lock may be hold. Defaults to 60000 = 1 minute.

LockAssociations

The LockAssociations entry defines the behaviour for the OJB implicit locking feature.
If set to WRITE (default) acquiring a write- lock on a given object x implies write locks on all objects associated to x.
If set to READ implicit read-locks are acquired. Acquiring a read-lock on x allways results in implicit read-locks on all associated objects.
Follow this link to learn more about the OJB LockManager.

useServer

The useServer entry determines if OJB runs in single VM or in client/server mode. The default value "false" launches single VM mode. "true" enables the client/server mode. To learn more about the OJB client/server mode follow this link.

BokerServers

The BokerServers entry is only evaluated if useServer=true. A OJB client will use the servers declared in this entry to perform its persistence operations. The entries must be separated by commas as follows:
BrokerServers=stella\:2001,luna\:2001
This settings tell the client that there are two servers stella and luna that have PersistenceBrokerServer processes listening on port 2001. The client will use these servers in a round-robin way to provide a simple load-balancing. The server must be specified by valid TCP/IP name or IP address.
To learn more about the OJB client/server mode follow this link.

ServerThreadCount

The ServerThreadCount entry tells the PersistenceBrokerServer how many worker threads have to be started initially. To learn more about the OJB client/server mode follow this link.

BrokerPoolSize

The BrokerPoolSize entry defines the number of PersistenceBrokers that reside in the BrokerPool of the PersistenceBrokerServer. To learn more about the OJB client/server mode follow this link.




$FOOTER$