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

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 
>> transaction
>> will not be applied.
>So I assume the client will get a failure code back.

Yes.


>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...

Kurt