Date: Sat, 13 Dec 1997 03:21:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: jb@freebsd1.cimlogic.com.au, tlambert@primenet.com, hackers@freebsd.org Subject: Re: Kernel Config datafile... Message-ID: <199712130321.UAA27603@usr04.primenet.com> In-Reply-To: <199712130135.MAA00829@word.smith.net.au> from "Mike Smith" at Dec 13, 97 12:05:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Actually, every time someone mentions the Windows Registry my hackles > come up at the suggestion that Microsoft somehow invented the concept, > or even got the bloody thing halfway *right*. > > Apollo did it *much* better, and it's beginning to sound like LDAP will > inherit the mantle. Not if it can't do transactions. For example, I want to change the local machines network configuration. The network configuration has to be atomically updated" you either update all of the fields, or none of them. The typical way you would implement this in LDAP (and in the Windows 95 registry) is to use an encapsulation object. Specifically, say I have an entry named 0x000000001. Inferior to this entry, I have: 0x000000001 hostname S myhostname domainname S domain.com ip_forwarding I 0x00000000 ... I should not refer to this directly. I should use a container object: hostdata current I 0x00000001 To atomically rewrite these key/value pairs as one transaction, I create a replacement record (which I update non-atomically): 0x0002713A5 hostname S newhostname domainname S newmain.com ip_forwarding I 0x00000001 ... Then I update the hostdata to point to the new container, like so: hostdata current I 0x0002713A5 The problem with this is that you must require that the application have the knowledge of the transaction. This is a bad thing, since it means you have to duplicate the transaction code in every application that accesses your directory (a registry is a directory). For LDAP, you can not be guaranteed that the back end code has properly committed the data from the new record before you rewrite hostdata/current with the new record's address. This means that an LDAP server is not very reliable in a "kill -9 everything" situation (the topological equivalent of a power failure or a kernel panic). For high-availability services, such as a directory *must* be, by definition, this is not acceptable. The Windows 95 Registry "brute forces" this by rolling the data files over on each transaction. This is (effectively) a two stage commit, and is reliable because the defeat file caching (there are flags to the write command to get this behaviour from VFAT; Windoes 95 must use these flags itself to do swapping). So for right now, the Windows 95 Registry beats LDAP. You *could* do a specific back-end implementation of your own, and use container records. This would guarantee transactions would be committed. Better to add a "unsigned long transaction_id" to each LDAP command; if you pass a 0, then the commit is a single datum commit, and not transacted; however, if you pass a value obtained from a call to id = ldap_begin_transaction(); (guaranteed to not be the special placeholder 0), and then when you are done, call: ldap_commit_transaction( id); or ldap_abort_transaction( id); and pass this "sync" event to the back end, then you could encapsulate the two stage commit such that container objects were not necessary. Really, LDAP is not mature enough at this point, except for embedded systems where you can guarantee the behaviour of the back end, and the back end is either not write-cached, or understands the significance of container objects implicit by hierarchy. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712130321.UAA27603>