[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: how to check uniqueness of uidNumber ?

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)


        //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;
          $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

return $change_entry["uidnumber"];
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. ;-)

Howard Chu wrote:
You 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.