[Date Prev][Date Next]
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?
> -----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
> 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
> 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
> >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...