> I made this point by cutting and pasting the command prototypes from the > manual and showing that one could not 1. Acquire and 2. Modify an entry > in one command given those prototypes. You can't modify something if you > don't know what it is RIGHT NOW. > Now one *can* implement a semaphore and check it prior to access in php > but it won't mean anything to someone accessing via a program or perl > script etc.
LDAP is not transaction, it doesn't need to be. > The only way around this problem that I know of is to use php to call > the ldap client binarys, i.e. ldapadd, ldapmodify etc. I'm suspicious > of them also, though. If you look at the C libarary you'll find that the PHP calls are more-or-less a 1:1 correspondance. man ldap_modify ldap_mod_add, ldap_mod_del, ldap_mod_replace just call ldap_modify with a different mod_op. You'd have to make repetitive calls to ldap_modify if you were writing in C, so the PHP implementation is imposing no additional problems > P.S. I look forward to being wrong about this but a review of the docs > shows that I am probably not. See below. Your technically not wrong, but you're think in relational database terms. If you need massive concurrent access to a volatile value then LDAP is probably the wrong tool; the contents of a directory service just doesn't exhibit those characteristics. Bulk updates/loads should be channeled through a single mechanism, and thus side step the whole problem. And division of labor reduces it even further. Only the customer support department modifies customer contact records, only the IT deptartment manages user objects, etc... > | ldap_modify() function is used to modify the exiting entries in the > LDAP directory. The structure of the entry is same as in ldap_add(). > | bool ldap_add ( resource link_identifier, string dn, array entry) > Whee, according to the doc, 'resource link_identifier' is the > connection, 'string dn' is who to bind as and 'array entry' is the > modified data. No ability to specify *what* to modify so we will have > to perform a separate action to retrieve this. In the meantime the data > has been changed by another process, perhaps. Perhaps, but in years I've never seen this happen or if it did it was totally innocuous. Two (or more) administrators are going to be modifying the DHCP stanza for a given subnet at exactly the same time? (Task management systems exist to avoid those types of problems). If you have some critical value you need to establish a broker, but the need is rare so why burden the whole system for a fringe case (this is not a relational database after all). LDAP is meant for use in applications where the read:write ratio is REALLY high. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
