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 – “LDAP Transactions” and “LDAP: 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:
CreateGroupingRequest ( 2.16.840.1.113719.1.27.103.1 ) – This is LDAP extended operation which allows grouping of related operations. The extended operation carries a value – createGroupType which identifies the type of grouping requested. For LDAP transactions, the grouping type is transactionGroupingType. ( 2.16.840.1.113719.1.27.103.8)
CreateGroupingResponse ( 2.16.840.1.113719.1.27.103.1 ) – This is the response of the LDAP server to the createGroupingRequest and contains 2 response fields – groupCookie and an optional createGroupValue.
GroupingControl ( 2.16.840.1.113719.1.27.103.7 ) - This is used to indicate association of an operation to a grouping via the groupCookie which is the value carried by this control.
EndGroupingRequest ( 2.16.840.1.113719.1.27.103.2 ) – This is another LDAP extended operation used to indicate the end of a grouping Request. In case of LDAP transactions, this indicates the settling of the transaction – resulting in a commit or an abort of the transaction.
EndGroupingResponse ( 2.16.840.1.113719.1.27.103.2 ) – This is the response of the LDAP server to the endGroupingResponse indicating either success or otherwise to the LDAP client.
Following is the sequence of requests and responses exchanged between the LDAP server and the LDAP client in an LDAP transaction:
If a client wants to send a number of LDAP operations to be processed by a server in an atomic operation, i.e., transaction, it should first send a createGroupingRequest, with a createGroupType of transactionGroupingType and no createGroupValue.
If the eDirectory server is capable of handling transactions, it sends back a success result code, with a groupingCookie, which uniquely identifies the grouping requested by the client. Otherwise, the server shall return a non-successful result code indicating the reason for the failure to the client.
If the client receives success result code from the server, it then attaches a GroupingControl, which includes the groupingCookie returned by the server, 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 client and server, the server 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 client shall result in a response containing a non-success 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”.
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 LDAP server to chain to another server.
Schema modifications and Modify DN 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 transaction within another is not supported.