Check and change as one action
01A directory stores entries: named objects with attributes and values. Lightweight Directory Access Protocol (LDAP) lets a client operate on those entries. An assertion is a condition the server checks before proceeding.
Now use a separate fixture whose current description is ready. The server tests and replaces it with done in one atomic Modify action.
Key idea: For updates and Compare, assertion evaluation and normal processing MUST form one atomic action.
Terms
- Directory entry
- A named object containing attributes and values.
- Assertion
- A condition tested against the operation’s target entry.
- Atomic action
- The test and the operation act together; another update cannot interleave between them.
Rules & examples
For updates and Compare, assertion evaluation and normal processing MUST form one atomic action.
- A separate read followed by a write can use stale information. RFC 4528 lets the server evaluate a condition as an integral part of the requested operation, rather than trusting an earlier client observation.
- For Compare and all update operations, checking the assertion and normal processing SHALL be one atomic action (§3). This is a guarantee about one operation, not a transaction over several requests or entries.
- The chosen entry is cn=picnic,dc=example. The condition is (description=ready), and the chosen Modify replacement is description=done. A competing client can change the value to busy before the guarded request arrives.
- If the applied assertion is FALSE or Undefined, resultCode assertionFailed(122) is returned and no further processing is performed. TRUE permits normal processing; it does not guarantee success.
- This finite model assumes the entry exists, the control is applied and normal processing succeeds in the positive case. Schema matching, permissions and other normal failures remain separate. Verified editorial erratum 7198 adds the missing word “of”; it changes no algorithm.
Ready/busy/done are fictional normalized fixture values. Equality follows the attribute’s schema-defined matching rule, not a general raw-string comparison. The model is a state transition, not a live LDAP server or concurrency implementation.
Sources
New to this? Start hereA quick picture + helpful background
Check the entry before changing it
Think of a shared directory card: a remembered value may be out of date by the time someone changes it. A conditional update asks the server to check the current card and perform the update as one action. This is an analogy for one operation, not a promise of a transaction across the whole directory.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.