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

Re: LDAP Transactions

It was interesting re-reading this thread.  It interesting
to see how easy it is for things to flounder on.  In fact,
my draft has been floundering for years, namely due to
lack of initial implementation (a problem I am not

Over the years, I have had folks ask to allow intermediate
states of the transaction be visible (such as to a search
operation).  I simply said that would violate the isolation
property of the transaction (I have defined a transaction
to be a single unit of interaction with ACID properties).
I also suggest that what they seem to want is a object
"lock" (and/or "rwlock") mechanism and that this is that.
That is, I have avoided (so far) floundering on
the details of isolation.   As a last resort, I will
simply say "no" to requirements that would lead to
floundering on the approach.


At 06:49 AM 3/7/2006, David Boreham wrote:

>The last time I tried this many years ago the thing floundered on
>the details of isolation. So you might watch out for that :
>clients will want to see varying levels of isolation depending
>on their goals. For example a client may want to see the
>effects of their updates reflected in searches that they perform
>within the same transaction. OTOH if one implements
>serializable isolation semantics then I believe it is impossible
>to avoid deadlocks and hence clients need to be taught
>how to detect them, back off and re-try.
>Follow this line of thought for a while and one (well,
>at least myself and the folk that were working on the
>project at the time) concludes that anyone needing
>transactions should use a RDBMS and LDAP is
>better off without them ;)
>My draft is probably somewhere out there in the googlesphere
>somewhere - I seem to remember it being similar to yours...
>Ah, here it is :
>The subsequent thread brings up some other points that
>I'd since forgotten.