LDIF Atomic Operations


The modify operation within LDAP is atomic by the RFC specification.

As near as we know no LDAP operation is atomic on more than one entry.

Multiple operations on a single entry within LDAP are NOT atomic under most circumstances.

Get and Increment#

As an example of an operation where atomicity is desired on a single entry we will use the uidNumber attribute form the POSIX schema. When adding posixAccount entries to LDAP the uidNumber needs to be unique for operational effectiveness. A common practice we have used is to store and attribute on an LDAP entry, usually an OU which holds the lastUidNumberAssigned.

When a new entry is added to the DIT we read the lastUidNumberAssigned increment is by one and then write the lastUidNumberAssigned back to the OU. The typical method would be to read the lastUidNumberAssigned value and then add 1 to the values and then write the values back to the lastUidNumberAssigned. If we would read the value 500 and then replace the value with 501. If this is done by a "normal" modify operation, there is a chance that the value could be assigned to two different users. A "normal" modify would be, expressed as LDIF:

dn: ou=users,dc=lastUidNumberAssigned,dc=com
changetype: modify
replace: lastUidNumberAssigned 
lastUidNumberAssigned : 501

However, there is a chance that the same value (500) could be read and assigned to two different user entries. To avoid this issue, a better method (We coan not guarantee this depending on you LDAP server vendor and LDAP architecture) would be to perform to LDAP modify operations within the same operation. Expressed as an LDIF it woudl loke like:

dn: ou=users,dc=willeke,dc=com
changetype: modify
delete: lastUidNumberAssigned 
lastUidNumberAssigned : 500
add: lastUidNumberAssigned 
lastUidNumberAssigned : 501

Although this woudl usually solve the issue, as the LDAP modify operation is atomic and the delete delete: lastUidNumberAssigned would fail if the existing value was not 500. If the operation succeeds, we know we've got a unique uidNumber.

However, it is not always that simple. If you are using a single-master the assurance is much higher. If you are using Novell's eDirectory, Active Directory or another multi-master server architecture, you could no be as certain. In multi-master replication there typically could be no guarantee that the lastUidNumberAssigned had not be updated on another server and the lastUidNumberAssigned value had simply not been replicated to the server you were performing the operation on.

More Information#

There might be more information for this subject on one of the following: