The Directory Proxy Server supports a globally unique attribute plugin that prevents any value within a defined set of attributes to appear more than once in any entry for one or more subtree views.

Administrators can also configure whether conflict validation should be checked before an add, modify, or modifyDN request to one or more backend servers or after the change has successfully completed.

For example, if the pre-commit-validation property is enabled, the Globally Unique Attribute Plugin performs one or more searches to determine whether any entries conflict with the change, such as add, modify, or modifyDN. If a conflict is detected, the change request is rejected. If the post-commit-validation property is enabled, the server performs one or more searches after the change has been processed to determine if a conflict was created in multiple servers at the same time. If a conflict is detected in this manner, an administrative alert is generated to notify administrators of the problem so that they can take any manual corrective action.

The Globally Unique Attribute plugin attempts to detect and prevent unique attribute conflicts for changes processed through this Directory Proxy Server, but it cannot detect conflicts introduced by changes applied by clients communicating directly with backend servers.

You should enable the plugin for all backend servers with the same configuration so that conflicts can be detected within individual backend server instances. However, the Unique Attribute plugin alone might not be sufficient for cases in which the content is split across multiple sets of servers, such as in an entry-balanced environment or in proxy configurations with different branches on different servers.

The LDAP SDK uniqueness request control can be used for enforcing uniqueness on a per-request basis. See the LDAP SDK documentation and the com.unboundid.ldap.sdk.unboundidds.controls.UniquenessResponseControl class for using the control. See the ASN.1 specification to implement support for it in other APIs.

Note:

Consider the following points about pre-commit validation versus post-commit validation:

  • Pre-commit validation is the only mechanism that can try to prevent conflicts. It increases the processing time for add, modify, or modifyDN operations because the necessary searches to look for conflicts happen before the update request is forwarded to any backend servers.
  • Post-commit validation only sends administrative alerts about conflicts that already exist in the data. It can't prevent conflicts, but can allow you to deal with them in a timely manner. It also operates during the post-response phase, so it does not affect the processing time for the associated write operation.

In most cases, pre-commit validation should be sufficient to prevent conflicts. However, you should periodically run the identify-unique-attribute-conflicts tool to find any conflicts that might have arisen.

Note:

If you want to mitigate any risks due to conflicts being generated by concurrent operations in different servers, then using both pre-commit-validation and post-commit-validation properties provides the best combination of preventing most conflicts in advance, and detecting and alerting about conflicts that arise from concurrent writes.