Note: this is an abstract component that cannot be instantiated.
The JE Backend uses the Berkeley DB Java Edition to store user-provided data in a local repository.
↓Direct Subcomponents
↓Parent Component
↓Properties
↓dsconfig Usage
The following JE Backends are available in the server :
These JE Backends inherit from the properties described below.
The JE Backend component inherits from the Backend
The properties supported by this managed object are as follows:
| Description | Specifies a name to identify the associated backend. The name must be unique among all backends in the server. The backend ID may not be altered after the backend is created in the server. |
| Default Value | None |
| Allowed Values | A string |
| Multi-Valued | No |
| Required | Yes |
| Admin Action Required | None. Modification requires no further action |
| Description | A description for this Backend |
| Default Value | None |
| Allowed Values | A string |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
| Description | Indicates whether the backend is enabled in the server. If a backend is not enabled, then its contents are not accessible when processing operations. |
| Default Value | None |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | Yes |
| Admin Action Required | None. Modification requires no further action |
| Description | Specifies the behavior that the backend should use when processing write operations. |
| Default Value | None |
| Allowed Values | enabled - Allows write operations to be performed in that backend (if the requested operation is valid, the user has permission to perform the operation, the backend supports that type of write operation, and the global writability-mode property is also enabled). disabled - Causes all write attempts to fail. internal-only - Causes external write attempts to fail but allows writes by replication and internal operations. |
| Multi-Valued | No |
| Required | Yes |
| Admin Action Required | None. Modification requires no further action |
| Description | Specifies the base DN(s) for the data that the backend handles. A single backend may be responsible for one or more base DNs. Note that no two backends may have the same base DN although one backend may have a base DN that is below a base DN provided by another backend (similar to the use of sub-suffixes in the Sun Java System Directory Server). If any of the base DNs is subordinate to a base DN for another backend, then all base DNs for that backend must be subordinate to that same base DN. |
| Default Value | None |
| Allowed Values | A valid DN. |
| Multi-Valued | Yes |
| Required | Yes |
| Admin Action Required | No administrative action is required by default although some action may be required on a per-backend basis before the new base DN may be used.
Although it is currently supported, the use of multiple base DNs per backend is not recommended and this capability may be removed in the future. If you are considering the use of multiple base DNs in a backend, you should first contact UnboundID support to discuss this configuration |
set-degraded-alert-when-disabled
| Description | Determines whether the Identity Data Store enters a DEGRADED state (and sends a corresponding alert) when this Backend is disabled. |
| Default Value | true |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
return-unavailable-when-disabled
| Description | Determines whether any LDAP operation that would use this Backend is to return UNAVAILABLE when this Backend is disabled. |
| Default Value | true |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
| Description | Specifies the path to the filesystem directory that is used to hold the Berkeley DB Java Edition database files containing the data for this backend. The files for this backend are stored in a sub-directory named after the backend-id. The path may be either an absolute path or a path relative to the directory containing the base of the Identity Data Store installation. The path may be any valid directory path in which the server has appropriate permissions to read and write files and has sufficient space to hold the database contents. |
| Default Value | db |
| Allowed Values | Unknown |
| Multi-Valued | No |
| Required | Yes |
| Admin Action Required | The Identity Data Store must be restarted for changes to this setting to take effect. Modification requires that the Identity Data Store be stopped, the database directory manually relocated, and then the Identity Data Store restarted. While the Identity Data Store is stopped, the directory and files pertaining to this backend in the old database directory must be manually moved or copied to the new location. |
| Description | Specifies the maximum number of entries that is allowed to match a given index key before that particular index key is no longer maintained. This property is analogous to the ALL IDs threshold in the Sun Java System Directory Server. Note that this is the default limit for the backend, and it may be overridden on a per-attribute basis. This property is related to the exploded-index-entry-threshold. |
| Default Value | 4000 |
| Allowed Values | An integer value. Lower limit is 1. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | If any index keys have already reached this limit, indexes must be rebuilt before they will be allowed to use the new limit. Setting a large limit (greater than 10,000) could have a big impact on write performance and database growth on disk. |
| Description | Specifies the percentage of JVM memory to allocate to the database cache. Specifies the percentage of memory available to the JVM that should be used for caching database contents. Note that this is only used if the value of the db-cache-size property is set to "0 MB". Otherwise, the value of that property is used instead to control the cache size configuration. |
| Default Value | 10 |
| Allowed Values | An integer value. Lower limit is 1. Upper limit is 90 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
| Description | The percentage of JVM memory to allocate to the database cache during import operations. Specifies the percentage of memory available to the JVM that should be used for caching database contents during import. Note that unlike db-cache-percent and db-cache-size, this value will always be used even if the db-cache-size property is set. Setting this value too large can have a large negative impact on import performance. It should not be set above the default unless the heap is over 16GB. |
| Default Value | 60 |
| Allowed Values | An integer value. Lower limit is 10. Upper limit is 80 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
| Description | Specifies the method that should be used to prime caches with data for this backend. If any priming is to be performed for the backend, then the prime method should be chosen based on the type of caching to be used. If the server will primarily rely upon the database cache, then the preload method should be used. If the server will primarily rely upon the filesystem cache, then any method may be used. Note that while the filesystem cache prime method may be fastest, it uses sequential reads of the database files, and some filesystems may bypass the filesystem cache if they detect that the application is performing a sequential read. In such cases, an alternate priming mechanism is preferred. When using a preload or preload-internal-nodes-only option, the cache-mode settings also affect what is preloaded. If a cache-mode is set to evict-leaf-immediately, then no leaf nodes will be preloaded for that index. If a cache-mode is set to evict-bin-immediately, the nothing will be preloaded for that index. |
| Default Value | none |
| Allowed Values | none - Do not attempt to prime the backend when it is initialized. preload - Use a database-specific preload mechanism to prime the contents of the backend into the database cache. This may also be effective for priming the filesystem cache. preload-internal-nodes-only - Use a database-specific preload mechanism to prime internal database structure information into the database cache, but do not prime any actual data. This will be faster than other prime methods, but the server caches may still need to "warm up" in order to achieve steady-state performance. It may be useful in environments in which a full prime is not required before the server begins accepting client requests. cursor-across-indexes - Use database cursors to iterate through backend contents. This is similar to (and likely slower than) using the preload mechanism, but it does provide the ability to continue priming even after the database cache has become full, which may also be beneficial when relying on the filesystem cache. prime-to-filesystem-cache - Use sequential reads across the database files in an attempt to prime the filesystem cache. This will likely be the fastest method when priming the filesystem cache, but will not prime the database cache. prime-to-filesystem-cache-non-sequential - Use non-sequential reads across the database files in an attempt to prime the filesystem cache. This will likely be the fastest method when priming the filesystem cache, but will not prime the database cache. |
| Multi-Valued | Yes |
| Required | No |
| Admin Action Required | None. Changes will automatically take effect the next time that a prime is initiated. |
| Description | Indicates whether to calculate and store a message digest of the entry contents along with the entry data, in order to provide a means of verifying the integrity of the entry data. If the entry digest is enabled, then it will always be written whenever an entry is created or updated. If the verify-entry-digests global configuration property is enabled, then the entry digest will be verified whenever an entry is read from the database; otherwise it will be ignored (but may still be used by other validation utilities). If this feature is enabled while there are already entries in the database, then those entries will remain without a message digest until they are updated, which will cause them to be re-written with a digest. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
deadlock-retry-limit (Advanced Property)
| Description | Specifies the number of times that the server should retry an attempted operation in the backend if a deadlock results from two concurrent requests that interfere with each other in a conflicting manner. A value of "0" indicates no limit. |
| Default Value | 10 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
is-private-backend (Advanced Property)
| Description | Indicates whether this backend should be considered a private backend in the server. Private backends are meant for storing server-internal information and should not be used for user or application data. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
import-temp-directory (Advanced Property)
| Description | Specifies the location of the directory that is used to hold temporary information during the index post-processing phase of an LDIF import. The specified directory is only used while an import is in progress and the files created in this directory are deleted as they are processed. It may be an absolute path or one that is relative to the instance root directory. |
| Default Value | import-tmp |
| Allowed Values | Unknown |
| Multi-Valued | No |
| Required | Yes |
| Admin Action Required | None. Changes do not take effect for any import that may already be in progress. |
import-thread-count (Advanced Property)
| Description | Specifies the number of threads to use for concurrent processing during an LDIF import. This should generally be a small multiple (for example, 2x) of the number of CPUs in the system for a traditional system, or equal to the number of CPU strands for a CMT system. |
| Default Value | 16 |
| Allowed Values | An integer value. Lower limit is 1. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes do not take effect for any import that may already be in progress. |
export-thread-count (Advanced Property)
| Description | Specifies the number of threads to use for concurrently retrieving and encoding entries during an LDIF export. A value of zero indicates that the value should be automatically tuned based on the number of available CPUs. |
| Default Value | 0 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes do not take effect for any export that may already be in progress. |
exploded-index-entry-threshold (Advanced Property)
| Description | Specifies the maximum number of entries that are allowed to match a given index key before that particular index key is stored in a separate database in an expanded format. A value of 0, or any value greater or equal to the index-entry-limit, means that the expanded index database will not be used. All keys whose entry count is less than exploded-index-entry-threshold are stored in one database in a consolidated format such that changes to the key require rewriting all the entry IDs matching the key. All keys whose entry count is greater than exploded-index-entry-threshold (but less than the index-entry-limit) are stored in a separate database in an expanded format such that changes to the key require writing only the updated entry ID. The consolidated format is very efficient for reads but the expanded format is far more efficient for writes. A large value for the exploded-index-entry-threshold can have a big impact on write performance and database growth on disk, since for each change to an index key stored in the consolidated format, IDs for all entries matching the key must be rewritten to the database. For example if the exploded-index-entry-threshold is set to 100,000, and the number of entries matching a given key is 50,000, then changes to that key will require writing 200KB to the database since each entry ID is 4 bytes. Add and delete operations are especially impacted since they must update all indexes for an entry. If many indexes have a large exploded-index-entry-threshold, this can lead to very low throughput and can cause the database to temporarily grow very large on disk. It's recommended to rarely set this value above 10,000 and never set it above 50,000. |
| Default Value | 4000 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | If any index keys have already reached this threshold, indexes need to be rebuilt before they are allowed to use the new threshold. Setting a large limit (greater than 10,000) could have a big impact on write performance and database growth on disk. |
id2children-index-entry-limit (Advanced Property)
| Description | Specifies the maximum number of entry IDs to maintain for each entry in the id2children system index (which keeps track of the immediate children for an entry, to assist in otherwise unindexed searches with a single-level scope). A value of 0 means there is no limit, however this could have a big impact on database size on disk and on server performance. |
| Default Value | The value of the index-entry-limit configuration option will be used. |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | If this limit is increased, then the contents of the backend must be exported to LDIF and re-imported to allow the new limit to be used for any id2children keys that had already hit the previous limit. |
id2subtree-index-entry-limit (Advanced Property)
| Description | Specifies the maximum number of entry IDs to maintain for each entry in the id2subtree system index (which keeps track of all descendants below an entry, to assist in otherwise unindexed searches with a whole-subtree or subordinate subtree scope). A value of 0 means there is no limit, however this could have a big impact on database size on disk and on server performance. |
| Default Value | The value of the index-entry-limit configuration option will be used. |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | If this limit is increased, then the contents of the backend must be exported to LDIF and re-imported to allow the new limit to be used for any id2subtree keys that had already hit the previous limit. |
db-directory-permissions (Advanced Property)
| Description | Specifies the permissions that should be applied to the directory containing the backend database files and to directories and files created during backup or LDIF export of the backend. They should be expressed as three-digit octal values, which is the traditional representation for UNIX file permissions. The three digits represent the permissions that are available for the directory's owner, group members, and other users (in that order), and each digit is the octal representation of the read, write, and execute bits. Execute permissions are only applied to directories. Note that this property only impacts permissions on the database directory and not on the files written into that directory. On UNIX systems, the user's umask controls permissions given to the database files. |
| Default Value | 700 |
| Allowed Values | Any octal value between 700 and 777 (the owner must always have read, write, and execute permissions on the directory). |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
subtree-delete-size-limit (Advanced Property)
| Description | Specifies the maximum number of entries that may be deleted from the backend when using the subtree delete control. If a subtree contains more than this number of entries, then it cannot be removed using the subtree delete control. A value of zero indicates that subtree delete operations will not be allowed. |
| Default Value | 5000 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
db-cache-size (Advanced Property)
| Description | The amount of JVM memory to allocate to the database cache. Specifies the amount of memory that should be used for caching database contents. A value of "0 MB" indicates that the db-cache-percent property should be used instead to specify the cache size. |
| Default Value | 0 MB |
| Allowed Values | A positive integer representing a size. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
compact-common-parent-dn (Advanced Property)
| Description | Provides a DN of an entry that may be the parent for a large number of entries in the backend. This may be used to help increase the space efficiency when encoding entries for storage. |
| Default Value | None |
| Allowed Values | A valid DN. |
| Multi-Valued | Yes |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
compress-entries (Advanced Property)
| Description | Indicates whether the backend should attempt to compress entries before storing them in the database. Note that this property applies only to the entries themselves and does not impact the index data. Further, the effectiveness of the compression is based on the type of data contained in the entry. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes to this setting take effect only for writes that occur after the change is made. It is not retroactively applied to existing data until those entries are updated. |
db-compact-key-prefixes (Advanced Property)
| Description | Indicates whether keys used in the backend B-tree databases should be compacted by extracting common prefixes. This reduces the memory and disk space required for storing the database. Setting this option translates to calling com.sleepycat.je.DatabaseConfig#setKeyPrefixing(true) for each database used in the backend. Testing has shown that this can reduce the memory required to cache the database environment by up to 10%. While this theoretically could impact performance, testing has demonstrated that it leads to an overall reduction in throughput of at most 1%. The memory savings of leaving this option enabled will almost always outweigh the potential performance impact. |
| Default Value | true |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes to this setting take effect once the backend is restarted but only for database entries that are updated after the change is made. To update all databases to use the new setting, export and re-import the data. |
db-cleaner-min-utilization (Advanced Property)
| Description | Specifies the minimum percentage of "live" data that the database cleaner attempts to keep in database log files. If the amount of live data in the database environment drops below this percentage, then the cleaner moves some live data to the end of the database. As a result of cleaning, some database log files may no longer contain live data. These files will be removed at the next checkpoint. |
| Default Value | 75 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 90 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
db-evictor-lru-only (Advanced Property)
| Description | Indicates whether the database should evict existing data from the cache based on an LRU policy (where the least recently used information will be evicted first). If set to "false", then the eviction keeps internal nodes of the underlying Btree in the cache over leaf notes, even if the leaf nodes have been accessed more recently. This may be a better configuration for databases in which only a very small portion of the data is cached. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-evictor-nodes-per-scan (Advanced Property)
| Description | Specifies the number of Btree nodes that should be evicted from the cache in a single pass if it is determined that it is necessary to free existing data in order to make room for new information. Changes to this property do not take effect until the backend is restarted. It is recommended that you also change this property when you set db-evictor-lru-only to false. This setting controls the number of Btree nodes that are considered, or sampled, each time a node is evicted. A setting of 100 often produces good results, but this may vary from application to application. The larger the nodes per scan, the more accurate the algorithm. However, setting it too high is detrimental; the need to consider larger numbers of nodes for each eviction may delay the completion of a given database operation, which will impact the response time of the application thread. |
| Default Value | 10 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 1000 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-evictor-critical-percentage (Advanced Property)
| Description | Specifies the percentage over the configured maximum that the database cache is allowed to grow. It is recommended to set this value slightly above zero when the database is too large to fully cache in memory. In this case, a dedicated background evictor thread is used to perform evictions once the cache fills up reducing the possibility that server threads are blocked. When the database is too large to fully cache in memory, the server threads that process operations are responsible for evicting data from the cache to make room for new data. This eviction process is typically fast, but it can block other server threads while it happens. To avoid this, it is recommended to set this property to a non-zero value (5 is typically enough), so that a dedicated thread begins evicting data from the cache once it is full. Server threads do not have to do any evictions unless the cache is more than the configured critical percentage above being 100% full. Changes to this property do not take effect until the backend is restarted. |
| Default Value | 0 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 100 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-log-file-max (Advanced Property)
| Description | Specifies the maximum size for a database log file. |
| Default Value | 50mb |
| Allowed Values | A positive integer representing a size. Lower limit is 1048576. Upper limit is 4294967296 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-logging-file-handler-on (Advanced Property)
| Description | Indicates whether the database should maintain a je.info file in the same directory as the database log directory. This file contains information about the internal processing performed by the underlying database. |
| Default Value | true |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-logging-level (Advanced Property)
| Description | Specifies the log level that should be used by the database when it is writing information into the je.info file. The database trace logging level is (in increasing order of verbosity) chosen from: OFF, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, ALL. |
| Default Value | CONFIG |
| Allowed Values | A string |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-checkpointer-wakeup-interval (Advanced Property)
| Description | Specifies the maximum length of time that should pass between checkpoints. |
| Default Value | 60s |
| Allowed Values | A duration. Lower limit is 1 milliseconds. Upper limit is 4294000 milliseconds. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-checkpointer-high-priority (Advanced Property)
| Description | Indicates whether the database checkpoint thread should run with a high priority. Configuring the checkpointer to use a high priority may help the checkpointer complete more quickly and can help the cleaner to keep up under heavy write load, at the expense of throughput and/or response time for those write operations. If this is enabled, then it may also be necessary to manually tune the number of cleaner threads using the db-num-cleaner-threads property. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-num-lock-tables (Advanced Property)
| Description | Specifies the number of lock tables that are used by the underlying database. This can be particularly important to help improve scalability by avoiding contention on systems with large numbers of CPUs. The value of this configuration property should be set to a prime number that is near the number of worker threads configured for use in the server. A value of zero will cause the server to attempt to automatically determine the best value for the underlying system. |
| Default Value | 0 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 32767 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-num-cleaner-threads (Advanced Property)
| Description | Specifies the number of threads that the backend should maintain to keep the database log files at or near the desired utilization. A value of zero indicates that the number of cleaner threads should be automatically configured based on the number of available CPUs. In environments with high write throughput, multiple cleaner threads may be required to maintain the desired utilization. If the number of cleaner threads is to be automatically tuned, then the number of threads will be set to one quarter of the number of available CPUs, with a minimum of 1 thread and a maximum of 16. |
| Default Value | 0 |
| Allowed Values | An integer value. Lower limit is 0. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
db-clean-on-explicit-gc (Advanced Property)
| Description | Indicates whether this backend should perform complete database cleaning when the server explicitly does a JVM garbage collection. This should rarely be set to true. When this is set to true, it is usually used as a piece of a larger strategy to reduce the impact of database cleaning on response times. This has only been in issue on certain CMT-based platforms that have very slow single-threaded performance. Typically, the strategy is to set this value to true, the db-run-cleaner property to false, to enable the Periodic GC Plugin to do periodic GCs, and the Identity Proxy is used to route around servers that are doing explicit garbage collections. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-txn-no-sync (Advanced Property)
| Description | Indicates whether database writes should be primarily written to an internal buffer but not immediately written to disk. Setting the value of this configuration attribute to "true" may improve write performance but could cause the most recent changes to be lost if the Identity Data Store or the underlying JVM exits abnormally, or if an OS or hardware failure occurs (a behavior similar to running with transaction durability disabled in the Sun Java System Directory Server). |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
db-txn-write-no-sync (Advanced Property)
| Description | Indicates whether the database should synchronously flush data as it is written to disk. If this value is set to "false", then all data written to disk is synchronously flushed to persistent storage and thereby providing full durability. If it is set to "true", then data may be cached for a period of time by the underlying operating system before actually being written to disk. This may improve performance, but could cause the most recent changes to be lost in the event of an underlying OS or hardware failure (but not in the case that the Identity Data Store or the JVM exits abnormally). |
| Default Value | true |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
db-background-sync-interval (Advanced Property)
| Description | Specifies the interval to use when performing background synchronous writes in the database environment in order to smooth overall write performance and increase data durability. A value of "0 s" will disable background synchronous writes. |
| Default Value | 1000 ms |
| Allowed Values | A duration. Lower limit is 0 milliseconds. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
prime-thread-count (Advanced Property)
| Description | Specifies the number of threads to use when priming. At present, this applies only to the preload and cursor-across-indexes prime methods. |
| Default Value | 2 |
| Allowed Values | An integer value. Lower limit is 1. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
prime-time-limit (Advanced Property)
| Description | Specifies the maximum length of time that the backend prime should be allowed to run. A duration of zero seconds indicates that there should not be a time limit. |
| Default Value | 0s |
| Allowed Values | A duration. Lower limit is 0 milliseconds. Upper limit is 2147483647 milliseconds. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes will automatically take effect the next time that a prime is initiated. |
prime-all-indexes (Advanced Property)
| Description | Indicates whether to prime all indexes associated with this backend, or to only prime the specified set of indexes (as configured with the system-index-to-prime property for the system indexes, and the prime-index property in the attribute index definition for attribute indexes). Note that this configuration property may be ignored for certain prime methods (e.g., prime-to-filesystem-cache) if it is not possible to target specific indexes. |
| Default Value | true |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes will automatically take effect the next time that a prime is initiated. |
continue-prime-after-cache-full (Advanced Property)
| Description | Indicates whether to continue processing the database prime after the database cache has become full. This configuration property applies only to the cursor-across-indexes prime method. When the preload method is selected, then the preload will end after the database cache has become full. When the prime-to-filesystem-cache method is selected, then all database files will be read. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes will automatically take effect the next time that a prime is initiated. |
system-index-to-prime (Advanced Property)
| Description | Specifies which system index(es) should be primed when the backend is initialized. This property will only be used if the prime-all-indexes property has a value of false. It may not be used for certain prime methods (e.g., prime-to-filesystem-cache) if it is not possible to target specific indexes. |
| Default Value | None |
| Allowed Values | dn2id - Index from normalized DN to entry ID. id2entry - Index from entry ID to the entire encoded entry. id2children - Index from entry ID to an entry ID list of its immediate children. id2subtree - Index from entry ID to an entry ID list of its subordinates. dn2uri - The referral database index that maps a normalized DN string to labeled URIs. |
| Multi-Valued | Yes |
| Required | No |
| Admin Action Required | None. Changes will automatically take effect the next time that a prime is initiated. |
system-index-to-prime-internal-nodes-only (Advanced Property)
| Description | Specifies the system index(es) for which internal nodes only should be primed when the backend is initialized. This property will only be used if the prime-all-indexes property has a value of false and the prime-method property has a value of preload. If a system index is contained in both the system-index-to-prime and the system-index-to-prime-internal-nodes-only properties, then the entire index will be primed rather than internal nodes only. |
| Default Value | None |
| Allowed Values | dn2id - Index from normalized DN to entry ID. id2entry - Index from entry ID to the full or partial encoded entry. uncached-id2entry - Index from entry ID to the full or partial encoded entry in a manner that should generally be less cached than id2entry. id2children - Index from entry ID to an entry ID list of its immediate children. id2subtree - Index from entry ID to an entry ID list of its subordinates. dn2uri - The referral database index that maps a normalized DN string to labeled URIs. |
| Multi-Valued | Yes |
| Required | No |
| Admin Action Required | None. Changes will automatically take effect the next time that a prime is initiated. |
background-prime (Advanced Property)
| Description | Indicates whether to attempt to perform the prime using a background thread if possible. If background priming is enabled, then the Identity Data Store may allowed to accept client connections and process requests while the prime is in progress. This configuration property applies only to the cursor-across-indexes and prime-to-filesystem-cache prime methods. Preload-based prime methods will never be processed with a background thread. |
| Default Value | false |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Changes will automatically take effect the next time that a prime is initiated. |
je-property (Advanced Property)
| Description | Specifies the database and environment properties for the Berkeley DB Java Edition database serving the data for this backend. Any Berkeley DB Java Edition property can be specified using the following form: property-name=property-value. Refer to the Identity Data Store documentation for further information on related properties, their implications, and range values. The definitive identification of all the property parameters is available in the example.properties file of Berkeley DB Java Edition distribution. |
| Default Value | None |
| Allowed Values | A string |
| Multi-Valued | Yes |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
num-recent-changes (Advanced Property)
| Description | Specifies the number of recent LDAP entry changes per replica for which the backend keeps a record to allow replication to recover in the event that the server is abruptly terminated. A value of "0" indicates that no recent changes are kept. |
| Default Value | 50000 |
| Allowed Values | An integer value. Lower limit is 0. Upper limit is 2147483647 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
db-use-thread-local-handles (Advanced Property)
| Description | Indicates whether to use thread-local database handles to reduce contention in the backend. |
| Default Value | true |
| Allowed Values | true false |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
default-cache-mode (Advanced Property)
| Description | Specifies the cache mode that should be used for any database for which the cache mode is not explicitly specified. |
| Default Value | default |
| Allowed Values | keep-hot - Records from this database should be kept hot in the cache, so that they are less likely to be evicted under memory pressure than records from databases with other cache modes. default - Records from this database should be given the default cache priority, which makes them more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot", but less likely to be evicted than with a cache mode of "make-cold". make-cold - Records from this database should be made cold in the cache, so that they are more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot" or "default". evict-leaf-immediately - Leaf nodes from this database should be evicted from the cache as soon as they are no longer needed by the operation referencing them, regardless of whether there is memory pressure. evict-bin-immediately - Entire BINs should be evicted from the cache as soon as possible when the associated leaf nodes are no longer needed by the operation referencing them, regardless of whether there is memory pressure. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
id2entry-cache-mode (Advanced Property)
| Description | Specifies the cache mode that should be used when accessing the records in the id2entry database, which provides a mapping between entry IDs and entry contents. |
| Default Value | The cache mode specified by the default-cache-mode property will be used. |
| Allowed Values | keep-hot - Records from this database should be kept hot in the cache, so that they are less likely to be evicted under memory pressure than records from databases with other cache modes. default - Records from this database should be given the default cache priority, which makes them more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot", but less likely to be evicted than with a cache mode of "make-cold". make-cold - Records from this database should be made cold in the cache, so that they are more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot" or "default". evict-leaf-immediately - Leaf nodes from this database should be evicted from the cache as soon as they are no longer needed by the operation referencing them, regardless of whether there is memory pressure. evict-bin-immediately - Entire BINs should be evicted from the cache as soon as possible when the associated leaf nodes are no longer needed by the operation referencing them, regardless of whether there is memory pressure. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
dn2id-cache-mode (Advanced Property)
| Description | Specifies the cache mode that should be used when accessing the records in the dn2id database, which provides a mapping between normalized entry DNs and the corresponding entry IDs. |
| Default Value | The cache mode specified by the default-cache-mode property will be used. |
| Allowed Values | keep-hot - Records from this database should be kept hot in the cache, so that they are less likely to be evicted under memory pressure than records from databases with other cache modes. default - Records from this database should be given the default cache priority, which makes them more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot", but less likely to be evicted than with a cache mode of "make-cold". make-cold - Records from this database should be made cold in the cache, so that they are more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot" or "default". evict-leaf-immediately - Leaf nodes from this database should be evicted from the cache as soon as they are no longer needed by the operation referencing them, regardless of whether there is memory pressure. evict-bin-immediately - Entire BINs should be evicted from the cache as soon as possible when the associated leaf nodes are no longer needed by the operation referencing them, regardless of whether there is memory pressure. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
id2children-cache-mode (Advanced Property)
| Description | Specifies the cache mode that should be used when accessing the records in the id2children database, which provides a mapping between the entry ID of a particular entry and the entry IDs of all of its immediate children. This index may be used when performing searches with a single-level scope if the search filter cannot be resolved to a small enough candidate list. |
| Default Value | The cache mode specified by the default-cache-mode property will be used. |
| Allowed Values | keep-hot - Records from this database should be kept hot in the cache, so that they are less likely to be evicted under memory pressure than records from databases with other cache modes. default - Records from this database should be given the default cache priority, which makes them more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot", but less likely to be evicted than with a cache mode of "make-cold". make-cold - Records from this database should be made cold in the cache, so that they are more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot" or "default". evict-leaf-immediately - Leaf nodes from this database should be evicted from the cache as soon as they are no longer needed by the operation referencing them, regardless of whether there is memory pressure. evict-bin-immediately - Entire BINs should be evicted from the cache as soon as possible when the associated leaf nodes are no longer needed by the operation referencing them, regardless of whether there is memory pressure. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
id2subtree-cache-mode (Advanced Property)
| Description | Specifies the cache mode that should be used when accessing the records in the id2subtree database, which provides a mapping between the entry ID of a particular entry and the entry IDs of all of its children to any depth. This index may be used when performing searches with a whole-subtree or subordinate-subtree scope if the search filter cannot be resolved to a small enough candidate list. |
| Default Value | The cache mode specified by the default-cache-mode property will be used. |
| Allowed Values | keep-hot - Records from this database should be kept hot in the cache, so that they are less likely to be evicted under memory pressure than records from databases with other cache modes. default - Records from this database should be given the default cache priority, which makes them more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot", but less likely to be evicted than with a cache mode of "make-cold". make-cold - Records from this database should be made cold in the cache, so that they are more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot" or "default". evict-leaf-immediately - Leaf nodes from this database should be evicted from the cache as soon as they are no longer needed by the operation referencing them, regardless of whether there is memory pressure. evict-bin-immediately - Entire BINs should be evicted from the cache as soon as possible when the associated leaf nodes are no longer needed by the operation referencing them, regardless of whether there is memory pressure. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
dn2uri-cache-mode (Advanced Property)
| Description | Specifies the cache mode that should be used when accessing the records in the dn2uri database, which provides a mapping between a normalized entry DN and a set of referral URLs contained in the associated smart referral entry. |
| Default Value | The cache mode specified by the default-cache-mode property will be used. |
| Allowed Values | keep-hot - Records from this database should be kept hot in the cache, so that they are less likely to be evicted under memory pressure than records from databases with other cache modes. default - Records from this database should be given the default cache priority, which makes them more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot", but less likely to be evicted than with a cache mode of "make-cold". make-cold - Records from this database should be made cold in the cache, so that they are more likely to be evicted under memory pressure than records from databases with a cache mode of "keep-hot" or "default". evict-leaf-immediately - Leaf nodes from this database should be evicted from the cache as soon as they are no longer needed by the operation referencing them, regardless of whether there is memory pressure. evict-bin-immediately - Entire BINs should be evicted from the cache as soon as possible when the associated leaf nodes are no longer needed by the operation referencing them, regardless of whether there is memory pressure. |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | The JE Backend must be disabled and re-enabled for changes to this setting to take effect. This modification requires that you disable and then re-enable this component for the change to take effect |
cleaner-thread-wait-time (Advanced Property)
| Description | Specifies the number of milliseconds the server should wait for cleaner threads to complete before closing the backend. The time in milliseconds that the server should wait for active cleaner threads to complete. |
| Default Value | 120000 |
| Allowed Values | An integer value. Lower limit is 1000. Upper limit is 3600000 . |
| Multi-Valued | No |
| Required | No |
| Admin Action Required | None. Modification requires no further action |
To list the configured Backends:
dsconfig list-backends
[--property {propertyName}] ...
To view the configuration for an existing Backend:
dsconfig get-backend-prop
--backend-name {name}
[--tab-delimited]
[--script-friendly]
[--property {propertyName}] ...
To update the configuration for an existing Backend:
dsconfig set-backend-prop
--backend-name {name}
(--set|--add|--remove) {propertyName}:{propertyValue}
[(--set|--add|--remove) {propertyName}:{propertyValue}] ...
To delete an existing Backend:
dsconfig delete-backend
--backend-name {name}