matthew sporleder wrote:
On 11/21/05, Pierangelo Masarati <[EMAIL PROTECTED]> wrote:
This would yield two advantages:
1) reduce by 1 the number of sync propagations in the typical case of no
conflicts
2) make the change immediately available on the server that received the
request
(dam'd: I should have patented this ;)
Sorry, I'd have beaten you to it... :P
http://www.openldap.org/lists/openldap-devel/200304/msg00007.html
If a link failure occurs on one node, the write wouldn't be guaranteed
to exist on all servers, which breaks the Atomicity and Durability
requirement of ACID. (I think the first step in a multi-master setup
should be ACID compliance, by the way).
I believe a journal and a staging database should be employed to first
record the write, and then test its application. If those are both
successful on all nodes, then a signal can be given to merge that
information into the production database at an agreed upon time.
That sounds like a distributed transaction manager, like Tuxedo.
BerkeleyDB can work with something like that, and we could implement it
in slapd without too much trouble. But it's quite different from what
most people here are asking for; the overhead for maintaining ACID would
drop write throughput to a few operations per second on a moderate sized
network.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
