The problem does not occur at the db level. It occurs at the script
level because one must first retrieve the uidNumber and then do the
modify. Between the two lines of code a race condition can possibly
occur between scripts. Here is an example function written in php:
function getnewuid ($ds)
{
$booleantest=FALSE;
//We get a number of retries equal to NUMRETRIES
for($idx=0; $idx < NUMRETRIES && !$booleantest ;$idx=$idx+1 )
{
$entries=ldap_get_entries($ds, ldap_search($ds, PROXYDN ,"cn=*"));
/*
If another such script starts AND finishes it's ldap_mod_replace
before we get ours started below, then we have a
race condition at the script level.
*/
if($entries[0]["uidnumber"][0] < MINUID )
$change_entry["uidnumber"] = MINUID;
else
$change_entry["uidnumber"] = $entries[0]["uidnumber"][0] + 1;
//This, at least, is atomic.
$booleantest=ldap_mod_replace($ds, PROXYDN, $change_entry);
}//end of for loop
if($booleantest)
return $change_entry["uidnumber"];
else
die("Timeout error! Unable to set uidNumber in PROXYDN. To many
users being added from other sources?\n");
}//end of function getnewuid ($ds)
So lets say that we have more than one person adding users using the
script in question. What if script A ends a search just as script B
starts a modify? If B somehow finishes the modify before A begins it's
modify, which could concievably happen despite the odds, then you wind
up with two users with the same uid. Problem is that we would rather
there be no chance at all. <grins and hikes up suspenders> After all,
we are not writin' Windoze code, here. ;-)
Post by Howard ChuYou don't need locks, LDAP already provides atomic actions. There's more than
one approach to solve a generic problem, you just have to understand the
approach that LDAP supports.
http://www.openldap.org/lists/openldap-software/200208/msg00358.html