[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Write-intensive LDAP
Hi Booker C. Bense,
> > As far as I can tell from the LDAP protocol spec and the C API spec, there
> > is no technical hindrance that would stop apps like this [...]
>
> - Read the protocol more closely. There is no support for transactions
> or locking.
I don't think that would have to be a problem.
A client that knows it's writing a lot can await a ModifyResponse before
sending a follow-up ModifyRequest. It can do this to sequence many writes,
or it can do this in a more subtle way, using a partially order to make
the requests only as sequential as needed. That would help, right?
Furthermore, I am assuming that the bulk of the operations comes from a
large number of connections from different clients. This is true for the
setup with resellers that I have in mind.
Different connections need not end up in a particular order if it's up to
me. But they shouldn't interfere in any other way than can be expected
from an arbitrary interleaving of the connections to the LDAP server. To
be clear: resellers are not assumed to be in contact.
> Any system that writes
> extensively to LDAP needs to support a complete rollback/queueing
> implementation outside of the protocol.
What would it add, given that the writes are more-or-less independent
and interchangeable?
> consistancy is what will bite you in the long run. LDAP works fine
> for WIRM applications ( write infrequently read many), it breaks
> horribly for write intensive applications.
Don't you mean that it's a property of a certain implementation, such as
LDAP? I see nothing wrong with the current protocol (as explained above)
and they don't make protocols that rely on such subjective grounds as
"infrequent".
I've seen several docs explaining how OpenLDAP writes to disk; they speak
of things like journals that are completely/linearly ordered in time; they
speak of the write-lock; they speak of soft updates (which I don't know).
Clearly, effort has been put in OpenLDAP to make it behave correct but
possibly slow under any sort of writing load.
Curious if you agree!
Cheers,
Rick van Rein.