com.sleepycat.je

Class DatabaseConfig

java.lang.Object

com.sleepycat.je.DatabaseConfig

All Implemented Interfaces:

java.lang.Cloneable

Direct Known Subclasses:

SecondaryConfig

public class DatabaseConfig
extends java.lang.Object
implements java.lang.Cloneable

Specifies the attributes of a database.

There are two groups of database attributes: per-database handle attributes, and database-wide attributes. An attribute may be persistent/transient or mutable/immutable:

Scope	Mutable	Persistent	Attribute
Database-wide attribute	True	True	btree comparator duplicate comparator key prefixing nodeMaxEntries
	True	False	deferred write transactional
	False	True	sorted duplicates
	False	False	temporary
Per-database handle attributes	False	False	allow create exclusive create read only getCacheMode() read only} use existing config

Persistent attributes will be saved in the log and remain in effect every time the environment is reopened. Transient attributes only remain in effect until:

• the database configuration is updated
• the database handle(per-database handle attributes) is closed, or all handles for this database (database-wide attributes) are closed.

Field Summary

Fields

Modifier and Type	Field and Description
static DatabaseConfig	DEFAULT An instance created using the default constructor is initialized with the system's default settings.

Constructor Summary

Constructors

Constructor and Description
DatabaseConfig() An instance created using the default constructor is initialized with the system's default settings.

Method Summary

Modifier and Type	Method and Description
DatabaseConfig	clone() Returns a copy of this configuration object.
DatabaseConfig	cloneConfig() Deprecated. As of JE 4.0.13, replaced by clone().
boolean	getAllowCreate() Returns true if the Environment.openDatabase method is configured to create the database if it does not already exist.
java.util.Comparator<byte[]>	getBtreeComparator() Returns the Comparator used for key comparison on this database.
boolean	getBtreeComparatorByClassName() Returns true if the btree comparator is set by class name, not by serializable Comparator object
CacheMode	getCacheMode() Returns the default CacheMode used for operations performed on this database, or null if the environment default is used.
boolean	getDeferredWrite() Returns the deferred-write option.
java.util.Comparator<byte[]>	getDuplicateComparator() Returns the Comparator used for duplicate record comparison on this database.
boolean	getDuplicateComparatorByClassName() Returns true if the duplicate comparator is set by class name, not by serializable Comparator object.
boolean	getExclusiveCreate() Returns true if the Environment.openDatabase method is configured to fail if the database already exists.
boolean	getKeyPrefixing() Returns the key prefixing configuration.
int	getNodeMaxDupTreeEntries() Deprecated. this property no longer has any effect and zero is always returned; getNodeMaxEntries() should be used instead.
int	getNodeMaxEntries() Returns the maximum number of children a B+Tree node can have.
boolean	getOverrideBtreeComparator() Returns the override setting for the btree comparator.
boolean	getOverrideDuplicateComparator() Returns the override setting for the duplicate comparator.
boolean	getReadOnly() Returns true if the database is configured in read-only mode.
boolean	getReplicated() Returns the replicated property for the database.
boolean	getSortedDuplicates() Returns true if the database is configured to support records with duplicate keys.
boolean	getTemporary() Returns the temporary database option.
boolean	getTransactional() Returns true if the database open is enclosed within a transaction.
boolean	getUseExistingConfig() Return the value of the useExistingConfig property.
DatabaseConfig	setAllowCreate(boolean allowCreate) Configures the Environment.openDatabase method to create the database if it does not already exist.
DatabaseConfig	setBtreeComparator(java.lang.Class<? extends java.util.Comparator<byte[]>> btreeComparatorClass) By default, a byte by byte lexicographic comparison is used for btree keys.
DatabaseConfig	setBtreeComparator(java.util.Comparator<byte[]> btreeComparator) By default, a byte by byte lexicographic comparison is used for btree keys.
DatabaseConfig	setCacheMode(CacheMode cacheMode) Sets the default CacheMode used for operations performed on this database.
DatabaseConfig	setDeferredWrite(boolean deferredWrite) Sets the deferred-write option.
DatabaseConfig	setDuplicateComparator(java.lang.Class<? extends java.util.Comparator<byte[]>> duplicateComparatorClass) By default, a byte by byte lexicographic comparison is used for duplicate data items in a duplicate set.
DatabaseConfig	setDuplicateComparator(java.util.Comparator<byte[]> duplicateComparator) By default, a byte by byte lexicographic comparison is used for duplicate data items in a duplicate set.
DatabaseConfig	setExclusiveCreate(boolean exclusiveCreate) Configure the Environment.openDatabase method to fail if the database already exists.
DatabaseConfig	setKeyPrefixing(boolean keyPrefixing) Configure the database to support key prefixing.
DatabaseConfig	setNodeMaxDupTreeEntries(int nodeMaxDupTreeEntries) Deprecated. this property no longer has any effect; setNodeMaxEntries(int) should be used instead.
DatabaseConfig	setNodeMaxEntries(int nodeMaxEntries) Configures the Environment.openDatabase method to have a B+Tree fanout of nodeMaxEntries.
DatabaseConfig	setOverrideBtreeComparator(boolean override) Sets to true if the database exists and the btree comparator specified in this configuration object should override the current comparator.
DatabaseConfig	setOverrideDuplicateComparator(boolean override) Sets to true if the database exists and the duplicate comparator specified in this configuration object should override the current comparator.
DatabaseConfig	setReadOnly(boolean readOnly) Configures the database in read-only mode.
DatabaseConfig	setReplicated(boolean replicated) Configures a database to be replicated or non-replicated, in a replicated Environment.
DatabaseConfig	setSortedDuplicates(boolean sortedDuplicates) Configures the database to support records with duplicate keys.
DatabaseConfig	setTemporary(boolean temporary) Sets the temporary database option.
DatabaseConfig	setTransactional(boolean transactional) Encloses the database open within a transaction.
DatabaseConfig	setUseExistingConfig(boolean useExistingConfig) Setting useExistingConfig to true allows a program to open a database without knowing a prior what its configuration is.
java.lang.String	toString() Returns the values for each configuration attribute.

Methods inherited from class java.lang.Object

equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Field Detail

DEFAULT

public static final DatabaseConfig DEFAULT

An instance created using the default constructor is initialized with the system's default settings.

Constructor Detail

DatabaseConfig

public DatabaseConfig()

An instance created using the default constructor is initialized with the system's default settings.

Method Detail

setAllowCreate

public DatabaseConfig setAllowCreate(boolean allowCreate)

Configures the Environment.openDatabase method to create the database if it does not already exist.

Parameters:

allowCreate - If true, configure the Environment.openDatabase method to create the database if it does not already exist.

Returns:

this

getAllowCreate

public boolean getAllowCreate()

Returns true if the Environment.openDatabase method is configured to create the database if it does not already exist.

This method may be called at any time during the life of the application.

Returns:

true if the Environment.openDatabase method is configured to create the database if it does not already exist.

setExclusiveCreate

public DatabaseConfig setExclusiveCreate(boolean exclusiveCreate)

Configure the Environment.openDatabase method to fail if the database already exists.

The exclusiveCreate mode is only meaningful if specified with the allowCreate mode.

Parameters:

exclusiveCreate - If true, configure the Environment.openDatabase method to fail if the database already exists.

Returns:

this

getExclusiveCreate

public boolean getExclusiveCreate()

Returns true if the Environment.openDatabase method is configured to fail if the database already exists.

This method may be called at any time during the life of the application.

Returns:

true if the Environment.openDatabase method is configured to fail if the database already exists.

setSortedDuplicates

public DatabaseConfig setSortedDuplicates(boolean sortedDuplicates)

Configures the database to support records with duplicate keys.

When duplicate keys are configured for a database, key prefixing is also implicitly configured. Without key prefixing, databases with duplicates would store keys inefficiently. Key prefixing is therefore mandatory for databases with duplicates.

Although two records may have the same key, they may not also have the same data item. Two identical records, that have the same key and data, may not be stored in a database.

The ordering of duplicates in the database is determined by the duplicate comparison function. See setDuplicateComparator(java.util.Comparator<byte[]>). If the application does not specify a duplicate comparison function, a default lexical comparison will be used.

If a primary database is to be associated with one or more secondary databases, it may not be configured for duplicates.

Calling this method affects the database, including all threads of control accessing the database.

If the database already exists when the database is opened, any database configuration specified by this method must be the same as the existing database or an error will be returned.

Parameters:

sortedDuplicates - If true, configure the database to support duplicate data items. A value of false is illegal to this method, that is, once set, the configuration cannot be cleared.

Returns:

this

getSortedDuplicates

public boolean getSortedDuplicates()

Returns true if the database is configured to support records with duplicate keys.

This method may be called at any time during the life of the application.

Returns:

true if the database is configured to support records with duplicate keys.

getKeyPrefixing

public boolean getKeyPrefixing()

Returns the key prefixing configuration. Note that key prefixing is always enabled for a database with duplicates configured.

Returns:

true if key prefixing has been enabled in this database.

setKeyPrefixing

public DatabaseConfig setKeyPrefixing(boolean keyPrefixing)

Configure the database to support key prefixing.

Key prefixing causes the representation of keys in the b-tree internal nodes to be split in each BIN (bottom internal node) between the common prefix of all keys and the suffixes. Using this often results in a more space-efficient representation in both the in-memory and on-disk formats. In general the cost of maintaining the prefix separately is low compared to the benefit, and therefore enabling key prefixing is strongly recommended.

When duplicate keys are configured for a database, key prefixing is also implicitly configured. Without key prefixing, databases with duplicates would store keys inefficiently. Key prefixing is therefore mandatory for databases with duplicates.

Parameters:

keyPrefixing - If true, enables keyPrefixing for the database.

Returns:

this

Throws:

java.lang.IllegalStateException - if the keyPrefixing argument is false and setSortedDuplicates(boolean) has been called to configure duplicates. Key prefixing is therefore mandatory for databases with duplicates.

See Also:

Cache Statistics: Size Optimizations

setTransactional

public DatabaseConfig setTransactional(boolean transactional)

Encloses the database open within a transaction.

If the call succeeds, the open operation will be recoverable. If the call fails, no database will have been created.

All future operations on this database, which are not explicitly enclosed in a transaction by the application, will be enclosed in in a transaction within the library.

Parameters:

transactional - If true, enclose the database open within a transaction.

Returns:

this

getTransactional

public boolean getTransactional()

Returns true if the database open is enclosed within a transaction.

This method may be called at any time during the life of the application.

Returns:

true if the database open is enclosed within a transaction.

setReadOnly

public DatabaseConfig setReadOnly(boolean readOnly)

Configures the database in read-only mode.

Any attempt to modify items in the database will fail, regardless of the actual permissions of any underlying files.

Parameters:

readOnly - If true, configure the database in read-only mode.

Returns:

this

getReadOnly

public boolean getReadOnly()

Returns true if the database is configured in read-only mode.

This method may be called at any time during the life of the application.

Returns:

true if the database is configured in read-only mode.

setNodeMaxEntries

public DatabaseConfig setNodeMaxEntries(int nodeMaxEntries)

Configures the Environment.openDatabase method to have a B+Tree fanout of nodeMaxEntries.

The nodeMaxEntries parameter is only meaningful if specified with the allowCreate mode. See EnvironmentConfig.NODE_MAX_ENTRIES for the valid value range, and the default value.

Parameters:

nodeMaxEntries - The maximum children per B+Tree node.

Returns:

this

setNodeMaxDupTreeEntries

public DatabaseConfig setNodeMaxDupTreeEntries(int nodeMaxDupTreeEntries)

Deprecated. this property no longer has any effect; setNodeMaxEntries(int) should be used instead.

getNodeMaxEntries

public int getNodeMaxEntries()

Returns the maximum number of children a B+Tree node can have.

This method may be called at any time during the life of the application.

Returns:

The maximum number of children a B+Tree node can have.

getNodeMaxDupTreeEntries

public int getNodeMaxDupTreeEntries()

Deprecated. this property no longer has any effect and zero is always returned; getNodeMaxEntries() should be used instead.

setBtreeComparator

public DatabaseConfig setBtreeComparator(java.util.Comparator<byte[]> btreeComparator)

By default, a byte by byte lexicographic comparison is used for btree keys. To customize the comparison, supply a different Comparator.

Note that there are two ways to set the comparator: by specifying the class or by specifying a serializable object. This method is used to specify a serializable object. The comparator class must implement java.util.Comparator and must be serializable. JE will serialize the Comparator and deserialize it when subsequently opening the database.

If a comparator needs to be initialized before it is used or needs access to the environment's ClassLoader property, it may implement the DatabaseComparator interface.

The Comparator.compare() method is passed the byte arrays that are stored in the database. If you know how your data is organized in the byte array, then you can write a comparison routine that directly examines the contents of the arrays. Otherwise, you have to reconstruct your original objects, and then perform the comparison. See the Getting Started Guide for examples.

WARNING: There are several special considerations that must be taken into account when implementing a comparator.

• Comparator instances are shared by multiple threads and comparator methods are called without any special synchronization. Therefore, comparators must be thread safe. In general no shared state should be used and any caching of computed values must be done with proper synchronization.
• Because records are stored in the order determined by the Comparator, the Comparator's behavior must not change over time and therefore should not be dependent on any state that may change over time. In addition, although it is possible to change the comparator for an existing database, care must be taken that the new comparator provides compatible results with the previous comparator, or database corruption will occur.
• JE uses comparators internally in a wide variety of circumstances, so custom comparators must be sure to return valid values for any two arbitrary keys. The user must not make any assumptions about the range of key values that might be compared. For example, it's possible for the comparator may be used against previously deleted values.

A special type of comparator is a partial comparator, which allows for the keys of a database to be updated, but only if the updates do not change the relative order of the keys. For example, if a database uses strings as keys and a case-insensitive comparator, it is possible to change the case of characters in the keys, as this will not change the ordering of the keys. Another example is when the keys contain multiple fields but uniquely identify each record with a single field. The partial comparator could then compare only the single identifying field, allowing the rest of the fields to be updated. A query (Cursor.getSearchKey, for example) could then be performed by passing a partial key that contains only the identifying field.

WARNING: To allow for key updates in situations like those described above, all partial comparators must implement the PartialComparator tag interface. Otherwise, BDB JE will raise an exception if an attempt is made to update a key in a database whose comparators do not implement PartialComparator. See "Upgrading from JE 5.0 or earlier" in the change log and the PartialComparator javadoc for more information.

Another special type of comparator is a binary equality comparator, which considers two keys to be equal if and only if they have the same length and they are equal byte-per-byte. All binary equality comparators must implement the BinaryEqualityComparator interface. The significance of binary equality comparators is that they make possible certain internal optimizations, like the "blind puts" optimization, described in BinaryEqualityComparator

The comparator for an existing database will not be overridden unless setOverrideBtreeComparator() is set to true.

Returns:

this

setBtreeComparator

public DatabaseConfig setBtreeComparator(java.lang.Class<? extends java.util.Comparator<byte[]>> btreeComparatorClass)

By default, a byte by byte lexicographic comparison is used for btree keys. To customize the comparison, supply a different Comparator.

Note that there are two ways to set the comparator: by specifying the class or by specifying a serializable object. This method is used to specify a Comparator class. The comparator class must implement java.util.Comparator and must have a public zero-parameter constructor. JE will store the class name and instantiate the Comparator by class name (using Class.forName and newInstance) when subsequently opening the database. Because the Comparator is instantiated using its default constructor, it should not be dependent on other constructor parameters.

The Comparator.compare() method is passed the byte arrays that are stored in the database. If you know how your data is organized in the byte array, then you can write a comparison routine that directly examines the contents of the arrays. Otherwise, you have to reconstruct your original objects, and then perform the comparison. See the Getting Started Guide for examples.

If a comparator needs to be initialized before it is used or needs access to the environment's ClassLoader property, it may implement the DatabaseComparator interface.

WARNING: There are several special considerations that must be taken into account when implementing a comparator.

• Comparator instances are shared by multiple threads and comparator methods are called without any special synchronization. Therefore, comparators must be thread safe. In general no shared state should be used and any caching of computed values must be done with proper synchronization.
• Because records are stored in the order determined by the Comparator, the Comparator's behavior must not change over time and therefore should not be dependent on any state that may change over time. In addition, although it is possible to change the comparator for an existing database, care must be taken that the new comparator provides compatible results with the previous comparator, or database corruption will occur.
• JE uses comparators internally in a wide variety of circumstances, so custom comparators must be sure to return valid values for any two arbitrary keys. The user must not make any assumptions about the range of key values that might be compared. For example, it's possible for the comparator may be used against previously deleted values.

A special type of comparator is a partial comparator, which allows for the keys of a database to be updated, but only if the updates do not change the relative order of the keys. For example, if a database uses strings as keys and a case-insensitive comparator, it is possible to change the case of characters in the keys, as this will not change the ordering of the keys. Another example is when the keys contain multiple fields but uniquely identify each record with a single field. The partial comparator could then compare only the single identifying field, allowing the rest of the fields to be updated. A query (Cursor.getSearchKey, for example) could then be performed by passing a partial key that contains only the identifying field.

WARNING: To allow for key updates in situations like those described above, all partial comparators must implement the PartialComparator tag interface. See "Upgrading from JE 5.0 or earlier" in the change log and the PartialComparator javadoc for more information.

Another special type of comparator is a binary equality comparator, which considers two keys to be equal if and only if they have the same length and they are equal byte-per-byte. All binary equality comparators must implement the BinaryEqualityComparator interface. The significance of binary equality comparators is that they make possible certain internal optimizations, like the "blind puts" optimization, described in BinaryEqualityComparator

The comparator for an existing database will not be overridden unless setOverrideBtreeComparator() is set to true.

Returns:

this

getBtreeComparator

public java.util.Comparator<byte[]> getBtreeComparator()

Returns the Comparator used for key comparison on this database.

getBtreeComparatorByClassName

public boolean getBtreeComparatorByClassName()

Returns true if the btree comparator is set by class name, not by serializable Comparator object

Returns:

true if the comparator is set by class name, not by serializable Comparator object.

setOverrideBtreeComparator

public DatabaseConfig setOverrideBtreeComparator(boolean override)

Sets to true if the database exists and the btree comparator specified in this configuration object should override the current comparator.

Parameters:

override - Set to true to override the existing comparator.

Returns:

this

getOverrideBtreeComparator

public boolean getOverrideBtreeComparator()

Returns the override setting for the btree comparator.

setDuplicateComparator

public DatabaseConfig setDuplicateComparator(java.util.Comparator<byte[]> duplicateComparator)

By default, a byte by byte lexicographic comparison is used for duplicate data items in a duplicate set. To customize the comparison, supply a different Comparator.

Note that there are two ways to set the comparator: by specifying the class or by specifying a serializable object. This method is used to specify a serializable object. The comparator class must implement java.util.Comparator and must be serializable. JE will serialize the Comparator and deserialize it when subsequently opening the database.

The Comparator.compare() method is passed the byte arrays that are stored in the database. If you know how your data is organized in the byte array, then you can write a comparison routine that directly examines the contents of the arrays. Otherwise, you have to reconstruct your original objects, and then perform the comparison. See the Getting Started Guide for examples.

If a comparator needs to be initialized before it is used or needs access to the environment's ClassLoader property, it may implement the DatabaseComparator interface.

WARNING: There are several special considerations that must be taken into account when implementing a comparator.

• Comparator instances are shared by multiple threads and comparator methods are called without any special synchronization. Therefore, comparators must be thread safe. In general no shared state should be used and any caching of computed values must be done with proper synchronization.
• Because records are stored in the order determined by the Comparator, the Comparator's behavior must not change over time and therefore should not be dependent on any state that may change over time. In addition, although it is possible to change the comparator for an existing database, care must be taken that the new comparator provides compatible results with the previous comparator, or database corruption will occur.
• JE uses comparators internally in a wide variety of circumstances, so custom comparators must be sure to return valid values for any two arbitrary keys. The user must not make any assumptions about the range of key values that might be compared. For example, it's possible for the comparator may be used against previously deleted values.

A special type of comparator is a partial comparator, which allows for the keys of a database to be updated, but only if the updates do not change the relative order of the keys. For example, if a database uses strings as keys and a case-insensitive comparator, it is possible to change the case of characters in the keys, as this will not change the ordering of the keys. Another example is when the keys contain multiple fields but uniquely identify each record with a single field. The partial comparator could then compare only the single identifying field, allowing the rest of the fields to be updated. A query (Cursor.getSearchKey, for example) could then be performed by passing a partial key that contains only the identifying field.

When using a partial duplicates comparator, it is possible to update the data for a duplicate record, as long as only the non-identifying fields in the data are changed. See Cursor.putCurrent for more information.

WARNING: To allow for key updates in situations like those described above, all partial comparators must implement the PartialComparator tag interface. See "Upgrading from JE 5.0 or earlier" in the change log and the PartialComparator javadoc for more information.

Another special type of comparator is a binary equality comparator, which considers two keys to be equal if and only if they have the same length and they are equal byte-per-byte. All binary equality comparators must implement the BinaryEqualityComparator interface. The significance of binary equality comparators is that they make possible certain internal optimizations, like the "blind puts" optimization, described in BinaryEqualityComparator

The comparator for an existing database will not be overridden unless setOverrideDuplicateComparator() is set to true.

setDuplicateComparator

public DatabaseConfig setDuplicateComparator(java.lang.Class<? extends java.util.Comparator<byte[]>> duplicateComparatorClass)

By default, a byte by byte lexicographic comparison is used for duplicate data items in a duplicate set. To customize the comparison, supply a different Comparator.

Note that there are two ways to set the comparator: by specifying the class or by specifying a serializable object. This method is used to specify a Comparator class. The comparator class must implement java.util.Comparator and must have a public zero-parameter constructor. JE will store the class name and instantiate the Comparator by class name (using Class.forName and newInstance) when subsequently opening the database. Because the Comparator is instantiated using its default constructor, it should not be dependent on other constructor parameters.

The Comparator.compare() method is passed the byte arrays that are stored in the database. If you know how your data is organized in the byte array, then you can write a comparison routine that directly examines the contents of the arrays. Otherwise, you have to reconstruct your original objects, and then perform the comparison. See the Getting Started Guide for examples.

If a comparator needs to be initialized before it is used or needs access to the environment's ClassLoader property, it may implement the DatabaseComparator interface.

WARNING: There are several special considerations that must be taken into account when implementing a comparator.

• Comparator instances are shared by multiple threads and comparator methods are called without any special synchronization. Therefore, comparators must be thread safe. In general no shared state should be used and any caching of computed values must be done with proper synchronization.
• Because records are stored in the order determined by the Comparator, the Comparator's behavior must not change over time and therefore should not be dependent on any state that may change over time. In addition, although it is possible to change the comparator for an existing database, care must be taken that the new comparator provides compatible results with the previous comparator, or database corruption will occur.
• JE uses comparators internally in a wide variety of circumstances, so custom comparators must be sure to return valid values for any two arbitrary keys. The user must not make any assumptions about the range of key values that might be compared. For example, it's possible for the comparator may be used against previously deleted values.

A special type of comparator is a partial comparator, which allows for the keys of a database to be updated, but only if the updates do not change the relative order of the keys. For example, if a database uses strings as keys and a case-insensitive comparator, it is possible to change the case of characters in the keys, as this will not change the ordering of the keys. Another example is when the keys contain multiple fields but uniquely identify each record with a single field. The partial comparator could then compare only the single identifying field, allowing the rest of the fields to be updated. A query (Cursor.getSearchKey, for example) could then be performed by passing a partial key that contains only the identifying field.

When using a partial duplicates comparator, it is possible to update the data for a duplicate record, as long as only the non-identifying fields in the data are changed. See Cursor.putCurrent for more information.

WARNING: To allow for key updates in situations like those described above, all partial comparators must implement the PartialComparator tag interface. See "Upgrading from JE 5.0 or earlier" in the change log and the PartialComparator javadoc for more information.

Another special type of comparator is a binary equality comparator, which considers two keys to be equal if and only if they have the same length and they are equal byte-per-byte. All binary equality comparators must implement the BinaryEqualityComparator interface. The significance of binary equality comparators is that they make possible certain internal optimizations, like the "blind puts" optimization, described in BinaryEqualityComparator

The comparator for an existing database will not be overridden unless setOverrideDuplicateComparator() is set to true.

Returns:

this

getDuplicateComparator

public java.util.Comparator<byte[]> getDuplicateComparator()

Returns the Comparator used for duplicate record comparison on this database.

getDuplicateComparatorByClassName

public boolean getDuplicateComparatorByClassName()

Returns true if the duplicate comparator is set by class name, not by serializable Comparator object.

Returns:

true if the duplicate comparator is set by class name, not by serializable Comparator object.

setOverrideDuplicateComparator

public DatabaseConfig setOverrideDuplicateComparator(boolean override)

Sets to true if the database exists and the duplicate comparator specified in this configuration object should override the current comparator.

Parameters:

override - Set to true to override the existing comparator.

Returns:

this

getOverrideDuplicateComparator

public boolean getOverrideDuplicateComparator()

Returns the override setting for the duplicate comparator.

setTemporary

public DatabaseConfig setTemporary(boolean temporary)

Sets the temporary database option.

Temporary databases operate internally in deferred-write mode to provide reduced disk I/O and increased concurrency. But unlike an ordinary deferred-write database, the information in a temporary database is not durable or persistent.

A temporary database is not flushed to disk when the database is closed or when a checkpoint is performed, and the Database.sync method may not be called. When all handles for a temporary database are closed, the database is automatically removed. If a crash occurs before closing a temporary database, the database will be automatically removed when the environment is re-opened.

Note that although temporary databases can page to disk if the cache is not large enough to hold the databases, they are much more efficient if the database remains in memory. See the JE FAQ on the Oracle Technology Network site for information on how to estimate the cache size needed by a given database.

See the Getting Started Guide, Database chapter for a full description of temporary databases.

Parameters:

temporary - if true, the database will be opened as a temporary database.

Returns:

this

getTemporary

public boolean getTemporary()

Returns the temporary database option.

Returns:

boolean if true, the database is temporary.

setDeferredWrite

public DatabaseConfig setDeferredWrite(boolean deferredWrite)

Sets the deferred-write option.

Deferred-write databases have reduced disk I/O and improved concurrency. Disk I/O is reduced when data records are frequently modified or deleted. The information in a deferred-write database is not guaranteed to be durable or persistent until Database.close() or Database.sync() is called, or a checkpoint is performed. Since the usual write ahead logging system is relaxed in order to improve performance, if the environment crashes before a Database.sync() or Database.close(), none, all, or a unpredictable set of the operations previously done may be persistent.

After a deferred-write database is closed it may be re-opened as an ordinary transactional or non-transactional database. For example, this can be used to initially load a large data set in deferred-write mode and then switch to transactional mode for subsequent operations.

Note that although deferred-write databases can page to disk if the cache is not large enough to hold the databases, they are much more efficient if the database remains in memory. See the JE FAQ on the Oracle Technology Network site for information on how to estimate the cache size needed by a given database.

See the Getting Started Guide, Database chapter for a full description of deferred-write databases.

Parameters:

deferredWrite - if true, the database will be opened as a deferred-write database.

Returns:

this

getDeferredWrite

public boolean getDeferredWrite()

Returns the deferred-write option.

Returns:

boolean if true, deferred-write is enabled.

setUseExistingConfig

public DatabaseConfig setUseExistingConfig(boolean useExistingConfig)

Setting useExistingConfig to true allows a program to open a database without knowing a prior what its configuration is. For example, if you want to open a database without knowing whether it contains sorted duplicates or not, you can set this property to true. In general, this is used by the JE utilities, to avoid having to know the configuration of a database. The databases should be opened readOnly when this property is set to true.

Parameters:

useExistingConfig - true if this Database should be opened using the existing configuration.

Returns:

this

getUseExistingConfig

public boolean getUseExistingConfig()

Return the value of the useExistingConfig property.

Returns:

the value of the useExistingConfig property.

setCacheMode

public DatabaseConfig setCacheMode(CacheMode cacheMode)

Sets the default CacheMode used for operations performed on this database. If this property is non-null, it overrides the default specified using EnvironmentMutableConfig.setCacheMode(com.sleepycat.je.CacheMode) for operations on this database. The default cache mode may be overridden on a per-record or per-operation basis using Cursor.setCacheMode(com.sleepycat.je.CacheMode), ReadOptions.setCacheMode(CacheMode) or WriteOptions.setCacheMode(CacheMode).

Parameters:

cacheMode - is the default CacheMode used for operations performed on this database. If null is specified, the environment default will be used.

Since:

4.0.97

See Also:

for further details.

getCacheMode

public CacheMode getCacheMode()

Returns the default CacheMode used for operations performed on this database, or null if the environment default is used.

Returns:

the default CacheMode used for operations performed on this database, or null if the environment default is used.

Since:

4.0.97

See Also:

setCacheMode(com.sleepycat.je.CacheMode)

setReplicated

public DatabaseConfig setReplicated(boolean replicated)

Configures a database to be replicated or non-replicated, in a replicated Environment. By default this property is true, meaning that by default a database is replicated in a replicated Environment.

In a non-replicated Environment, this property is ignored. All databases are non-replicated in a non-replicated Environment.

See Also:

Non-replicated Databases in a Replicated Environment

getReplicated

public boolean getReplicated()

Returns the replicated property for the database.

This method returns true by default. However, in a non-replicated Environment, this property is ignored. All databases are non-replicated in a non-replicated Environment.

See Also:

setReplicated(boolean)

cloneConfig

public DatabaseConfig cloneConfig()

Deprecated. As of JE 4.0.13, replaced by clone().

Returns a copy of this configuration object.

clone

public DatabaseConfig clone()

Returns a copy of this configuration object.

Overrides:

clone in class java.lang.Object

toString

public java.lang.String toString()

Returns the values for each configuration attribute.

Overrides:

toString in class java.lang.Object

Returns:

the values for each configuration attribute.