Re: Transactions in LDAP

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 10:35 PM 9/20/00 +0530, Anandi D. Herlekar wrote:
>Hi,
>Sorry to trouble you again..
>Here are some more questions 
>
>> The I-D describes only protocol extension.  A client could
>> today implement this extension using the existing API using
>> ldap_extended_operation() and ldap_*_ext()  calls.  It is
>> not necessary to provide a higher level "transaction API"
>> (though one might as such might be nice).
>
>1. Are these extended APIs implemented in current version of SLAPD?

OpenLDAP 2.0 implements draft-ietf-ldapext-ldap-c-api-04.txt.
As this is a client side API, it's implemented in -lldap -llber,
not slapd.

>The 
>documentation exist as draft, and I could not find any manual information on 
>these. 

Yes.  As previously noted, section 3 of the manual needs to be
updated.  Feel free to contribute changes.

>2. I am confused about what you said about pushing the transaction to the 
>backend. One transaction in LDAP could involve many transactions on the 
>Backend. (Actually, one ldap operation like ldap_add involves many 
>transactions on backend. if ldbm is used as a backend, add will involve 
>adding mappings in id2children.dbb, dn2id.dbb etc. This is ensured to be 
>atomic currently.) Are you planning to add apis to the backend for 
>trasactions?  If yes, then it would be back-end specific and would need 
>such support from all the backends. Is my interpretation correct or am I 
>missing something?

First, I plan on implementing DB transactions (not to be confused
with LDAP transactions) in a "replacement" backend.  Basically,
each LDAP update operation will be done as one database
"transaction".  This DB transaction may include any number of
database operations (get/put).  The DB transaction will be committed
if the LDAP result to be returned is Success, otherwise the
DB transaction will be aborted.

Then, I will implement LDAP transactions operations.  The first
implementation will be simple.  On LDAP start transaction, a
database transaction will be started.  Each LDAP update operation
within the LDAP transaction will be done as above excepting the
the per-operation DB transaction will be nested inside the
LDAP transaction's DB tranaction.  On LDAP end transaction, the
database transaction is committed or aborted as directed by
the client.

As previously noted, this implementation approach has a number of
flaws... namely it can hold write locks for extended periods
of time will be likely prone to death by dead lock avoidance.

A better approach is defer nested LDAP operations until the
LDAP end transaction is received (using CSN to ensure consistency
properties).

Kurt