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”.
There are few entities which figure in the context of LDAP transactions:
- CreateGroupingRequest (2.16.840.1.113718.104.22.168.1)
- CreateGroupingResponse (2.16.840.1.113722.214.171.124.1)
- GroupingControl (2.16.840.1.1137126.96.36.199.7)
- EndGroupingRequest (2.16.840.1.1137188.8.131.52.2)
- EndGroupingResponse (2.16.840.1.1137184.108.40.206.2)
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 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.1137220.127.116.11.4 ). Subsequent use of cookie by the DUA shall result in a response containing a non-success LDAP Result Code.
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.
Nesting of one LDAP Transaction within another is not supported.