[Date Prev][Date Next]
RE: Transactions in LDAP
At 01:51 PM 9/21/00 -0400, Loth, Karen K (Karen) wrote:
>> >Secondly, how are transactions going to be treated when a
>> referral comes
>> >into play?
>> The operation will not be reviewed as being successful, the
>> will not be applied.
>So I assume the client will get a failure code back.
>What if the following
>happens. Upon creation of a directory all branches of the tree reside on
>the same server. All client application code is written under this
>assumption. And transaction management works just fine. Then, for whatever
>reason, a given branch must be moved to another server. Now all of a sudden
>the client application code is broken. How is this going to be dealt with?
It's not going to be dealt with. I've designed an LDAP client/server
transaction capability. If higher level capabilities are desired,
they can be built on top of the this capability (if appropriate).
>> >Does the transaction cross over to the new directory?
>> The mechanism is between an LDAP client and an LDAP server, so no.
>Another question I have concerns replication. If the transaction fails on
>the slave server, will the master server also back out the change?
All update transactions upon slaves will fail (with referrals) as
slaves are read-only. There is nothing to backout.
>I know transaction management is in early stages of design, but these are
>just some areas to consider.
I have... and I've decided not to tackle distributed transactions
nor transactions in multi-master environments. These are complex
problems which are not readily solvable.
LDAP transactions (as I've proposed them) allow a client to
atomically update of two (or more) entries within the same
partition of a namingContext by directly interacting with
the mastering server. This is a readily solvable problem.
I would note that such a capability would be needed to implement
higher level transaction capabilities...