RE: Transactions in LDAP

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

At 04:04 PM 9/18/00 -0400, Loth, Karen K (Karen) wrote:
>Kurt,
>  A few questions about your transaction implementation.

It's doesn't exist.  I'm working on a replacement backend which
will be designed to support such.  Until I finish the replacement
backend, I won't start implementing LDAP transactions (as proposed
in my IETF draft).

>Do the LDAP transactions sit above a backend db's transaction processing?

I haven't decided how LDAP transactions will map on to DB transactions.
I am considering two different approaches:
  1) start LDAP transaction starts a DB transaction
     LDAP operations are "nested"
     end LDAP transaction commits the DB transaction
  2) start LDAP transaction initiates entry/CSN recording
     LDAP operations are recorded with entry/CSN they act upon
       but are NOT applied.
     end transaction locks each entry, checks CSN, applies changes,
         commits to DB.

There are obvious trade-offs.  Likely I'll implement 1) as the
first cut, but I believe 2) is best as it avoid holding of
entry locks across multiple LDAP operations.

>For example say the client did something like this:
>txnID = beginTransaction()
>    ldap_add_t()
>    ldap_add_t()
>    ldap_add_t()
>endTransaction()
>And the backend database is implemented in such a way that each add call is
>within a single database transaction.  So the second ldap_add_t() fails,
>what will get rolled back?  Will the LDAP server inform the backend database
>to delete (rollback) the first ldap_add_t()?

A transaction is the grouping of multiple operations into one atomic
action.  Each of operation within the grouping must succeed or no
change is made to the data.

>Secondly, how are transactions going to be treated when a referral comes
>into play?

The operation will not be reviewed as being successful, the transaction
will not be applied.


>Does the transaction cross over to the new directory?

The mechanism is between an LDAP client and an LDAP server, so no.