The Core of ADSI's Efficiency: The Property Cache

Active Directory Service Interfaces (ADSI) implements a process in which it first writes an object and its properties to an area of memory called the property cache. You then use the IADs interface’s SetInfo method to write the contents of the property cache to the LDAP: namespace in AD. Almost every write operation in ADSI requires a call to the SetInfo method to commit the changes to the directory. You might be wondering why ADSI initially writes changes to the property cache rather than the directory and whether data can become stale as a result.

Why Does ADSI Use the Property Cache?
Writing changes to the property cache is a more efficient use of network bandwidth than writing changes to the directory. ADSI consolidates attribute changes in the property cache, committing the changes only when you call the SetInfo method. However, some exceptions exist. Such important changes as object deletions, password changes, and group membership changes are immediately and automatically committed to the directory and bypass the property cache entirely.

The property cache minimizes network traffic for not only write operations but also read operations. Whenever you bind to an object and request the value of a property, ADSI makes an implicit call to the IADs interface’s GetInfo method to populate the property cache. This operation loads all populated attribute values into the property cache, which lets ADSI service all subsequent calls for values from the property cache rather than the directory. Because ADSI eliminates repeated network traversal, its use of network and system resources is efficient.

Can the Data Get Stale?
Whenever administrators discuss caching, a question about whether the data gets stale almost always comes up. To answer this question within the context of ADSI, consider this scenario: An administrator has changed the value of the IADsUser interface’s LastName property from Smith to Jones but hasn’t called the SetInfo method yet. Because ADSI services all subsequent property calls from the property cache, queries for the user’s last name will reflect the new value Jones, even though AD still holds the old value Smith for the User object’s LastName property. Hence, no problem exists.

What if the administrator needs to cancel the change to the property value? If he wants to return the cached value back to Smith, he needs to repopulate the property cache with that value. The administrator could store the Smith value in a variable and use that variable to change the cached value. However, a more elegant approach is to use the IADs interface’s GetInfo or GetInfoEx method to force a cache refresh. Just as ADSI initially populated the property cache with an implicit call to GetInfo, you can make an explicit call to GetInfo to repopulate the cache with the values stored in AD. In many cases, however, you need only roll back one property value, so GetInfoEx presents an even better solution. Using GetInfoEx, you can repopulate the property cache property by property, further conserving network bandwidth.