This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
EDirectory LDAP Transaction
EDirectory LDAP Transaction

Version management

Difference between version and

At line 1 added 43 lines
!!! Overview
[{$pagename}]
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:
* [CreateGroupingRequest] ([2.16.840.1.113719.1.27.103.1])
* [CreateGroupingResponse] ([2.16.840.1.113719.1.27.103.1])
* [GroupingControl] ([2.16.840.1.113719.1.27.103.7])
* [EndGroupingRequest] ([2.16.840.1.113719.1.27.103.2])
* [EndGroupingResponse] ([2.16.840.1.113719.1.27.103.2])
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
%%category [eDirectory]%%
e
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop