Usage

Edit online

Transactions are limited to a single connection to a single IBM® Security Verify Directory and are supported by the LDAP extended operations APIs.

Only one transaction at a time can be running over the same connection. During the transaction, no non-transactional operations can be issued over the same connection.

A transaction consists of three parts:
  • An extended request to start the transaction
  • Update operations:
    • add
    • modify
    • modify rdn
    • delete
    Note: The current release does not support some operations. For example, bind, unbind, search, extended op, and other operations. Referral objects can be updated only with manageDsaIT control specified.
  • An extended request to end the transaction
To start a transaction, the client must send an extended request in the form of:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 


requestValue [1] OCTET STRING OPTIONAL }
When the server receives the request, it generates a unique transaction ID. It then sends back an extended response in the form of: 
ExtendedResponse ::= [APPLICATION 24]SEQUENCE{

COMPONENTS OF LDAPResult,

responseName [10] LDAPOID OPTIONAL,

response [11] OCTET STRING OPTIONAL }
The client submits subsequent update operations asynchronously with a control attached to all operations. The control contains the transaction ID returned in the StartTransaction response. The control has the form of: 
Control ::= SEQUENCE {
 
controlType LDAPOID,

criticality BOOLEAN DEFAULT FALSE,
 
controlValue OCTET STRING OPTIONAL }

The server does not process update operations immediately. Instead, it saves the necessary information of operations in a queue.

The client sends an extended request to end the transaction that either commits or rolls back the transaction. If the server receives the commit operation result, it uses a global writer lock to serialize the transaction. It then retrieves the set of update operations that are identified by the transaction ID from the queue and begins to run these operations. If all operations succeed, the results are committed to the database and the server sends back the success return code.

As each operation is run, it generates a success return code unless an error occurs during the transaction. In this case, an unsuccessful return code is returned for all the operations. If any operation fails, the server rolls back the transaction and sends back the error return code of the failed operation. It sends to the operation in the client that caused the failure. The EndTransaction operation also receives an unsuccessful return code if the transaction is not successful. For any subsequent update operations that remain in the queue, an unsuccessful return code is generated. When the transaction times out, the connection is dropped and any subsequent operations receive an unsuccessful return code.

The server releases the global lock after the commit or the rollback is run. The event notification and change log operations are run only if the transaction succeeds.