Overview#
EDirectory LDAP Transaction
eDirectory LDAP server supports clubbing of multiple update operations into a single atomic operation - also called a transaction. The support for transactions over LDAP in eDirectory is based on two Internet specifications – Lightweight Directory Access Protocol (LDAP) Transactions and “LDAPv3 Grouping of Related Operations”.
LDAP Transactions allow an LDAP application to send several LDAP update operations (add, modify, delete, rename) as a group and then commit or abort this whole group of operations.
There are few entities which figure in the context of LDAP transactions:
Following is the sequence of requests and responses exchanged between the LDAP server and the LDAP client in an LDAP transaction:
- If a DUA wants to send a number of LDAP Message to be processed by a DSA in an atomic operation, i.e., transaction, it should first send a createGroupingRequest, with a createGroupType of transactionGroupingType and no createGroupValue.
- If the eDirectory DSA is capable of handling transactions, it sends back a success Result Code, with a groupingCookie, which uniquely identifies the grouping requested by the DUA. Otherwise, the DSA shall return a non-successful Result Code indicating the reason for the failure to the DUA.
- If the DUA receives success Result Code from the DSA, it then attaches a GroupingControl, which includes the groupingCookie returned by the DSA, to subsequent update operations to indicate that they are to be processed as part of a single transaction. If the server is willing and able to process the update operation as part of the transaction, the server shall return success and put this request in a queue. If the server is unwilling or unable to process the update operation as part of the transaction, the server shall return a non-successful result code indicating the reason for the failure to the client.
- After the client has sent all the update operations accompanied by the grouping control to the server, the client sends an endGroupingRequest with the groupingCookie to the server to indicate that it wants to settle the transaction. The absence of endGroupValue indicates a commit request where as presence of an empty endGroupValue indicates abort request.
- The server applies all the pending operations in one transaction. If it succeeds, it shall return success. Otherwise, it shall return a non-successful result code.
- If at any time during the above exchange between the DUA and DSA, the DSA is unwilling or unable to continue the specification of a transaction, the server issues an endGroupingNotice (2.16.840.1.113719.1.27.103.4 ). Subsequent use of cookie by the DUA shall result in a response containing a non-success LDAP Result Code.
The support for LDAP Transactions is indicated by the presence of the transactionGroupingType in the supportedGroupingTypes attribute of the rootDSE entry.
The LDAP Transaction implementation in eDirectory is based on a dated version of the LDAP Transaction specification. The latest revision of the LDAP transactions draft as of this writing is available at "Lightweight Directory Access Protocol (LDAP) Transactions".
13.5.1 Limitations#
The
LDAP Transactions feature has the following limitations:
All the objects affected by the operations grouped as a transaction need to be hosted locally on the server. None of these operations should require the DSA to chain to another server.
Schema modifications and ModifyDNRequest operation (Subtree move?) is NOT allowed to be grouped in an LDAP Transaction.
Passwords and attributes with stream syntax cannot be added as part of an LDAP Transaction.
Nesting of one LDAP Transaction within another is not supported.
Category#
eDirectory
e
There might be more information for this subject on one of the following: