Overview | Package | Class | Use | Tree | Deprecated | Index | Help
| Berkeley DB Java Edition version 4.0.103
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## com.sleepycat.je
Class DatabaseConfig

    java.lang.Object
      com.sleepycat.je.DatabaseConfig

All Implemented Interfaces:
  Cloneable

Direct Known Subclasses:
  SecondaryConfig

    public class DatabaseConfig

extends Object
implements Cloneable

Specifies the attributes of a database.

Field Summary
`static DatabaseConfig` | `DEFAULT` An instance created using the default constructor is initialized with the system's default settings.

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

Method Summary
`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.
`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.
`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()` Returns the maximum number of children a B+Tree duplicate tree node can have.
`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` | `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(Class<? extends Comparator<byte[]>> btreeComparatorClass)` By default, a byte by byte lexicographic comparison is used for btree keys.
`DatabaseConfig` | `setBtreeComparator(Comparator<byte[]> btreeComparator)` By default, a byte by byte lexicographic comparison is used for btree keys.
`void` | `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(Class<? extends Comparator<byte[]>> duplicateComparatorClass)` By default, a byte by byte lexicographic comparison is used for duplicate data items in a duplicate set.
`void` | `setDuplicateComparator(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 keyPrefixingEnabled)` Configure the database to support key prefixing.
`DatabaseConfig` | `setNodeMaxDupTreeEntries(int nodeMaxDupTreeEntries)` Configures the `Environment.openDatabase` method to have a B+Tree duplicate tree fanout of nodeMaxDupTreeEntries.
`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` | `setSortedDuplicates(boolean duplicatesAllowed)` 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 priori what its configuration is.
`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 duplicatesAllowed)

  Configures the database to support records with duplicate keys.

  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)`. 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:
    `duplicatesAllowed` - 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.

  Returns:
    true if key prefixing has been enabled in this database.

### setKeyPrefixing

    public DatabaseConfig setKeyPrefixing(boolean keyPrefixingEnabled)

  Configure the database to support key prefixing. Key prefixing causes the representation of keys in the b-tree internal nodes to be split between the common prefix of all keys and the suffixes. Using this may result in a more space-efficient representation in both the in-memory and on-disk formats, but at some possible performance cost.

  Parameters:
    `keyPrefixingEnabled` - If true, enables keyPrefixing for the database.
  Returns:
    this

### 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.

  Parameters:
    `nodeMaxEntries` - The maximum children per B+Tree node.
  Returns:
    this

### setNodeMaxDupTreeEntries

    public DatabaseConfig setNodeMaxDupTreeEntries(int nodeMaxDupTreeEntries)

  Configures the `Environment.openDatabase` method to have a B+Tree duplicate tree fanout of nodeMaxDupTreeEntries.

  The nodeMaxDupTreeEntries parameter is only meaningful if specified with the allowCreate mode.

  Parameters:
    `nodeMaxDupTreeEntries` - The maximum children per duplicate B+Tree node.
  Returns:
    this

### 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()

  Returns the maximum number of children a B+Tree duplicate 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 duplicate tree node can have.

### setBtreeComparator

    public DatabaseConfig setBtreeComparator(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.

  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 compares a proper subset (not all bytes) of the key. A partial comparator allows uniquely identifying a record by a partial key value. For example, the key could contain multiple fields but could uniquely identify the record with a single field. The partial comparator could then compare only the single identifying field. A query (`Cursor.getSearchKey`, for example) could then be performed by passing a partial key that contains only the identifying field.

  A partial comparator has limited value when used as a Btree comparator. Instead of using a partial comparator, the non-identifying fields of the key could be placed in the data portion of the key/data pair. This makes the key smaller, which normally provides better performance. A partial comparator is much more useful when used as a duplicate comparator (see `setDuplicateComparator`).

  However, if you do use a partial comparator as a Btree comparator, be aware that you may not configure the database for duplicates (true may not be passed to `setSortedDuplicates`). In a duplicate set, each key must have the same (identical bytes) key. The internal structure of JE's Btree cannot support duplicates with non-identical keys, and cannot support specifying non-identical keys for addressing the records in a duplicate set.

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

  Returns:
    this

### setBtreeComparator

    public DatabaseConfig setBtreeComparator(Class<? extends 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.

  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 compares a proper subset (not all bytes) of the key. A partial comparator allows uniquely identifying a record by a partial key value. For example, the key could contain multiple fields but could uniquely identify the record with a single field. The partial comparator could then compare only the single identifying field. A query (`Cursor.getSearchKey`, for example) could then be performed by passing a partial key that contains only the identifying field.

  A partial comparator has limited value when used as a Btree comparator. Instead of using a partial comparator, the non-identifying fields of the key could be placed in the data portion of the key/data pair. This makes the key smaller, which normally provides better performance. A partial comparator is much more useful when used as a duplicate comparator (see `setDuplicateComparator`).

  However, if you do use a partial comparator as a Btree comparator, please be aware that you may not configure the database for duplicates (true may not be passed to `setSortedDuplicates`). In a duplicate set, each key must have the same (identical bytes) key. The internal structure of JE's Btree cannot support duplicates with non-identical keys, and cannot support specifying non-identical keys for addressing the records in a duplicate set.

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

  Returns:
    this

### getBtreeComparator

    public 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 void setDuplicateComparator(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.

  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 is a comparator that compares a proper subset (not all bytes) of the data. A partial comparator allows uniquely identifying a record within a duplicate set by a partial data value. For example, the data could contain multiple fields but could uniquely identify the record with a single field. The partial comparator could then compare only the single identifying field. A query (`Cursor.getSearchBoth`, for example) could then be performed by passing a partial data value that contains only the identifying field.

  When using a partial 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.

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

### setDuplicateComparator

    public DatabaseConfig setDuplicateComparator(Class<? extends 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.

  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 is a comparator that compares a proper subset (not all bytes) of the data. A partial comparator allows uniquely identifying a record within a duplicate set by a partial data value. For example, the data could contain multiple fields but could uniquely identify the record with a single field. The partial comparator could then compare only the single identifying field. A query (`Cursor.getSearchBoth`, for example) could then be performed by passing a partial data value that contains only the identifying field.

  When using a partial 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.

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

  Returns:
    this

### getDuplicateComparator

    public 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 priori 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 void 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)`.

  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)`

### 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 `Object`

### toString

    public String toString()

  Returns the values for each configuration attribute.

  Overrides:
    `toString` in class `Object`
  Returns:
    the values for each configuration attribute.

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
| Berkeley DB Java Edition version 4.0.103
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright (c) 2004-2010 Oracle. All rights reserved.