> 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 [EMAIL PROTECTED]
