Package org.opends.server.backends.pluggable

Class EntryContainer

java.lang.Object
org.opends.server.backends.pluggable.EntryContainer
All Implemented Interfaces:
ConfigurationChangeListener<PluggableBackendCfg>
public final class EntryContainer extends Object implements ConfigurationChangeListener<PluggableBackendCfg>
Storage container for LDAP entries. Each base DN of a backend is given its own entry container. The entry container is the object that implements the guts of the backend API methods for LDAP operations.

Avoiding deadlocks

To eliminate the risk of deadlocks all database operations either take care to only hold a single record lock at a time, or ensure that records are locked in a well-defined order. Firstly, indexes are accessed in the following order:
  1. dn2id
  2. id2childrenCount (parent count)
  3. dn2uri
  4. id2childrenCount (total count)
  5. attribute and big indexes (ordered by index name)
  6. VLV indexes (ordered by index name)
  7. id2entry
Within an index records are locked in key order. Note that read operations use read-committed isolation, which generally means that access order is unimportant because record read locks are released immediately. However, there is one important exception, which occurs when performing unindexed searches. These use a cursor to iterate over dn2id and then read id2entry for each iteration. The read of id2entry will be performed while the cursor holds a lock on the current dn2id record.