[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Transactions in LDAP

  A few questions about your transaction implementation.

Do the LDAP transactions sit above a backend db's transaction processing?
For example say the client did something like this:
txnID = beginTransaction()
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()?

Secondly, how are transactions going to be treated when a referral comes
into play?  Does the transaction cross over to the new directory?

Karen Loth
Lucent Technologies 

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Monday, September 18, 2000 11:07 AM
> To: Anandi D. Herlekar
> Cc: openldap-devel@OpenLDAP.org
> Subject: Re: Transactions in LDAP
> At 02:30 PM 9/18/00 +0530, Anandi D. Herlekar wrote:
> >We are working on implementing transactions in LDAP.
> So am I.  :-)
> >We are refering to 
> >the internet draft 
> >draft-zeilenga-ldap-txn-00.txt.
> Note that there are no implementations of this I-D yet.
> We have much work to do in OpenLDAP before we're ready
> to provide transaction support.
> >We have following doubts:
> >If each beginTransaction is going to return a transaction ID, that 
> >will be passed to the following ldap apis, the signatures of 
> the APIs 
> >will change. i.e. each ldap API will have a corresponding 
> transaction 
> >API.
> 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).
> >Now, my basic doubt is, is such multithreading possible in 
> the current 
> >LDAP API version?
> With appropriate care.
> >I guess it must be possible, as the entries are locked.
> Threading of the LDAP API is independent of the threading of the
> server...
> >We need extra information in implementing transaction as we won't be 
> >unlocking the entry, untill the transaction is complete.
> Clients just need a transaction id to provide with each operation
> associated with the transaction.  How the server manages locks
> upon entry is a issue for the server...
> Kurt