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 modify DN 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 (i.e., add, modify, or modify DN). If a conflict is detected, then the change request will be rejected. If the post-commit-validation property is enabled, after the change has been processed, the server performs one or more searches to determine if a conflict was created in multiple servers at the same time. If a conflict is detected in this manner, then an administrative alert will be generated to notify administrators of the problem so that they can take any manual corrective action.

Note: The Globally Unique Attribute plugin will attempt to detect and/or 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.

We recommend that the Unique Attribute plugin be enabled 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 may not be sufficient for cases in which the content is split across multiple sets of servers (e.g., 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.

In general, note 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 will increase the processing time for add, modify, and modify DN operations because the necessary searches to look for conflicts happen before the update request is forwarded to any backend servers.
  • Post-commit validation will only let you know (via administrative alert) 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 won't affect the processing time for the associated write operation.
  • In most cases, pre-commit validation should be sufficient to prevent conflicts, although we recommend that you periodically run the identify-unique-attribute-conflicts tool to find any conflicts that may have arisen. 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.

For more detailed information about the plugin, see the Directory Proxy Server Reference (HTML)