Re: Re[4]: openldap-server-2.2.29: multimaster support

["John Madden" <jmadden@ivytech.edu>]

> Maybe we could use something like this:
> - the chain overlay attaches a control to the chained write that
> contains the entryUUID and the entryCSN
> - the producer processes the write; upon success, if the entryUUID and
> the entryCSN were the same, it returns a control response value that
> indicates the consumer can directly apply the write.

I wonder if Berkeley has any of this solved for us.  If perhaps a separate lock
manager process can attach to the DB environment and lock records, a process
outside of slapd could deal with locking on the request of the node of the
"cluster" wishing to write to an object.

Or could there be delegation of authority of objects?  In other words, upon
entrance into the cluster, the existing nodes negiotiate which pieces of the
directory are to be delegated to which nodes, who are then responsible for
maintaining their piece.  Every node has a complete replica of the directory, but
only serve authoritatively the piece that has been delegated to them and become
clients, connecting to the other nodes for the other pieces, regardless of write
or read (a sort of internal referral, one the client never sees).  If a client is
suddenly unreachable, negotiation is forced again among the remaining nodes.  I
don't know what the contents of the entryUUID are, but perhaps this could be used
to determing which entries are controlled by which nodes.  All changes are either
slurp'd or syncrepl'd to each node as normal.

Uhm, I believe we're now OT, at least for -software. :)

John





-- 
John Madden
UNIX Systems Engineer
Ivy Tech Community College of Indiana
jmadden@ivytech.edu