This class provides a request control which may be used to request that the
Directory Proxy Server forward the associated operation to a specific backend
set associated with an entry-balancing request processor. It may be either
an absolute routing request, indicating that the target backend set(s) are
the only ones that may be used to process the operation, or it may be used to
provide a routing hint in lieu of accessing the global index.
NOTE: This class, and other classes within the
com.unboundid.ldap.sdk.unboundidds
package structure, are only
supported for use against Ping Identity, UnboundID, and
Nokia/Alcatel-Lucent 8661 server products. These classes provide support
for proprietary functionality or for external specifications that are not
considered stable or mature enough to be guaranteed to work in an
interoperable way with other types of LDAP servers.
This control may be used for a number of different kinds of requests, as
follows:
- For an add request that uses absolute routing, exactly one target
backend set ID must be specified, and the request will be sent only to
that backend set.
WARNING: The use of absolute routing for an add
operation bypasses the check to ensure that no entry already exists
with the same DN as the new entry, so it is possible that an add
performed immediately below the balancing point could result in
creating an entry in one backend set with the same DN as another entry
in a different backend set. Similarly, if the entry-balancing request
processor is configured to broadcast add operations outside the
balancing point rather than relying on those adds to be replicated,
then it is strongly recommended that absolute routing not be used for
add operations outside the balancing point because that will cause the
entry to be added to only one backend set rather than to all backend
sets.
- For an add request that uses a routing hint, exactly one target backend
set ID must be specified for the first guess, although any number of
fallback set IDs may be specified. For entries immediately below the
balancing point, the routing hint will be used instead of a placement
algorithm in order to select which backend set should hold the entry
(and the fallback sets will not be used). For entries more than one
level below the balancing point, the routing hint will be used in lieu
of the global index as an attempt to determine where the parent entry
exists, and the fallback sets may be used if the parent entry doesn't
exist in the first guess set. For entries outside the balancing point,
if the entry-balancing request processor is configured to add entries
to one set and allow them to be replicated to other sets, then the
first guess hint will be used to select the set to which the entry will
be added (and the fallback sets will not be used). An add operation
with a routing hint cannot be used to create multiple entries with the
same DN in different backend sets, nor can it cause an entry outside
the balancing point to exist in only one backend set.
- For a simple bind request that uses absolute routing, exactly one
target backend set ID must be specified, and the request will be sent
only to that backend set. If the bind fails in that set, even if the
failure is because the target entry does not exist in that backend set,
then the failure will be returned to the client rather than attempting
the operation in a different backend set.
- For a simple bind request that uses a routing hint, exactly one target
backend set ID must be specified for the first guess, although any
number of fallback set IDs may be specified. If the bind fails in the
first guess set, it may be re-attempted in the fallback sets.
- For a compare request that uses absolute routing, exactly one target
backend set ID must be specified, and the request will be sent only to
that backend set. If the compare fails in that set, even if the
failure is because the target entry does not exist in that set, then
the failure will be returned to the client rather than attempting the
operation in a different backend set.
- For a compare request that uses a routing hint, exactly one target
backend set ID must be specified for the first guess, although any
number of fallback set IDs may be specified. If the compare operation
fails in the first guess set in a way that suggests the target entry
does not exist in that backend set, then it will be re-attempted in the
fallback sets.
- For a delete request that uses absolute routing, exactly one target
backend set ID must be specified, and the request will be sent only to
that backend set. If the delete fails in that set, even if the failure
is because the target entry does not exist in that set, then the
failure will be returned to the client rather than attempting the
operation in a different backend set.
WARNING: If the entry-balancing request processor is configured
to broadcast delete operations outside the balancing point rather than
relying on those deletes to be replicated, then it is strongly
recommended that absolute routing not be used for delete operations
outside the balancing point because that will cause the entry to be
deleted in only one backend set and will remain in all other backend
sets.
- For a delete request that uses a routing hint, exactly one target
backend set ID must be specified for the first guess, although any
number of fallback set IDs may be specified. For entries below the
balancing point, the routing hint will be used in lieu of the global
index in order to determine which backend set contains the target
entry. If the delete fails in the first guess set in a way that
suggests that the target entry does not exist in that backend set, then
it will be re-attempted in the fallback sets.
For entries outside the balancing point, if the entry-balancing request
processor is configured to delete entries from only one backend set
and allow that delete to be replicated to all other sets, then the
routing hint may be used to select the set from which that entry will
be deleted. A delete operation with a routing hint cannot be used to
cause an entry outside the balancing point to be removed from only one
backend set while leaving it in the remaining sets.
- For an atomic multi-update extended request, only absolute routing is
supported, and the route to backend set request control must be
attached to the extended operation itself and not to any of the
requests contained inside the multi-update. Exactly one backend set ID
must be specified, and the multi-update request will be sent only to
that backend set.
- For a non-atomic multi-update extended request, the extended operation
must not include a route to backend set request control. However, any
or all of the requests inside the multi-update request may include a
route to backend set request control, and in that case it will be
treated in the same way as for a request of the same type not
included in multi-update request (e.g., if a multi-update extended
operation includes an add request with a route to backend set request
control, then that route control will have the same effect as for the
same add request with the same control processed outside a multi-update
operation).
- For an extended request that will be processed by a proxied extended
operation handler, the request may include a route to backend set
request control and that control will be used to select the target
backend sets instead of the proxied extended operation handler's
selectBackendSets
method.
- For a modify request that uses absolute routing, exactly one target
backend set ID must be specified, and the request will be sent only to
that backend set. If the modify fails in that set, even if the failure
is because the target entry does not exist in that set, then the
failure will be returned to the client rather than attempting the
operation in a different backend set.
WARNING: When processing a modify operation against the
balancing point entry itself, the Directory Proxy Server will typically
send that modify request to all backend sets to ensure that it is
properly applied everywhere. However, with an absolute routing
request, the modify operation will be sent only to one backend set,
which will cause the entry in that set to be out of sync with the entry
in all other sets. It is therefore strongly recommended that absolute
routing not be used for modify operations that target the balancing
point entry. Similarly, if the entry-balancing request processor is
configured to broadcast modify operations targeting entries outside the
balancing point to all backend sets rather than having those modify
operations replicated to the other backend sets, it is strongly
recommended that absolute routing not be used for those operations
because the request will be sent to only one set, causing the entry in
that set to be out of sync with the corresponding entry in other
backend sets.
- For a modify request that uses a routing hint, exactly one target
backend set ID must be specified for the first guess, although any
number of fallback set IDs may be specified. For entries below the
balancing point, the routing hint will be used in lieu of the global
index in order to determine which backend set contains the target
entry. If the modify attempt fails in the first guess set in a way
that suggests the target entry does not exist in that backend set, then
it will be re-attempted in the fallback sets.
For modify operations that target the balancing point entry itself, the
entry-balancing request processor will send the request to all backend
sets, and the routing hint will not be used. Similarly, for entries
outside the balancing point, if the entry-balancing request processor
is configured to modify entries in only one backend set and allow that
modify operation to be replicated to all other sets, then the routing
hint may be used to select the set in which that entry will be
modified. A modify operation with a routing hint cannot be used to
cause an entry at or outside the balancing point to be updated in only
one backend set, leaving it out of sync with the corresponding entry in
the remaining sets.
- For a modify DN request that uses absolute routing, exactly one target
backend set ID must be specified, and the request wil be sent only to
that backend set. If the modify DN operation fails in that set, even
if the failure is because the target entry does not exist in that set,
then the failure will be returned to the client rather than attempting
the operation in a different backend set.
WARNING: Processing a modify DN operation with absolute routing
bypasses the check to ensure that the new DN for the target entry does
not conflict with the DN for an entry that exists in any other backend
set. As a result, you are strongly discouraged from using absolute
routing for any modify DN operation that would cause the new DN for the
entry to be exactly one level below the balancing point. Further, for
entries that exist outside the balancing point, if the entry-balancing
request processor is configured to broadcast modify DN operations
rather than expecting them to be replicated to the other backend sets,
a modify DN operation with absolute routing would cause the change to
be applied only in one backend set, leaving it out of sync with the
other sets.
- For a modify DN request that uses a routing hint, exactly one target
backend set ID must be specified for the first guess, although any
number of fallback set IDs may be specified. For entries below the
balancing point, the routing hint will be used in lieu of the global
index in order to determine which backend set contains the target
entry. If the modify attempt fails in the first guess set in a way
that suggests the target entry does not exist in that backend set, then
it will be re-attempted in the fallback sets.
For entries outside the balancing point, if the entry-balancing request
processor is configured to process modify DN operations in one backend
set and allow them to be replicated to other backend sets, then the
routing hint will be used to select which backend set should receive
the modify DN request. A modify DN operation with a routing hint
cannot be used to create a conflict in which the same DN exists in
multiple backend sets, or a case in which a modify DN operation outside
the balancing point leaves one backend set out of sync with the other
sets.
- For a search request that uses absolute routing, there may be multiple
target backend set IDs only if the scope of the search may include
data from multiple backend sets (i.e., the base DN is at or above the
balancing point, and the scope include entries at least one level below
the balancing point entry). If the base and scope of the search allow
it to match only entries at or above the balancing point or only
entries within one backend set, then the absolute routing request must
target exactly one backend set.
- For a search request that uses a routing hint, exactly one target
backend set ID must be specified for the first guess, although any
number of fallback set IDs may be specified. The routing hint will
only be used for cases in which the entire scope of the search is
contained entirely within a backend set (i.e., the entire scope is
at or above the balancing point, or the entire scope is at least one
level below the balancing point).
The OID for a route to backend set request control is
"1.3.6.1.4.1.30221.2.5.35", and the criticality may be either
true
or
false
. It must have a value with the following encoding:
RouteToBackendSetRequest ::= SEQUENCE {
entryBalancingRequestProcessorID OCTET STRING,
backendSets CHOICE {
absoluteRoutingRequest [0] SET OF OCTET STRING,
routingHint [1] SEQUENCE {
firstGuessSetIDs SET OF OCTET STRING,
fallbackSetIDs SET OF OCTET STRING OPTIONAL }
... }
... }
The use of the route to backend set request control will also cause the
server to behave as if the get backend set ID request control had been
included, so that the get backend set ID response control may be included in
operation result and search result entry messages as appropriate.