Understanding the ADSI Property Cache

In normal use, ADSI maintains a property cache of values for an object from the directory. The property cache contains an in-memory representation of the data on the server. All reads and writes are performed on the local cache and updates do not take effect until the cache is flushed.

The property cache is a great performance booster, as it reduces the number of remote LDAP messages that must be sent and received in order to work with an object's attribute data. Experienced architects know that any type of remote call over the network tends to be expensive, so making the calls "chunkier" rather than "chattier" is a great way to boost performance. With SDS and ADSI, much of this work is taken care of for us.

The property cache can be filled using the RefreshCache method. Additionally, some types of operations will force the property cache to be filled if it is not already. For example, accessing the attributes of a DirectoryEntry via the Properties property will force the cache to be loaded (if it was not previously loaded by another operation), as will accessing the Guid, Name, NativeGuid, SchemaClassName, or SchemaEntry property.

Calling RefreshCache with no arguments will cause all of the nonconstructed attributes for the object to be loaded. Calling RefreshCache with arguments allows us to load specific attributes we want into the cache. It also allows us to load a special type of Active Directory and ADAM attribute called a constructed attribute. Constructed attributes are not actually stored in the directory but are calculated on the fly by the directory. Constructed attributes are different from back-link attributes (see Chapter 7) in that they cannot be used in LDAP query filters. Some examples of useful constructed attributes are tokenGroups, allowedAttributesEffective, and canonicalName.

Tip: RefreshCache Can Increase Performance

Careful use of RefreshCache with arguments can also improve our performance, as only the data we need is read. However, we must make sure to get every attribute we are using, or we will end up accidentally doing a full cache load anyway.

 

Flushing Changes Back to the Directory

In order to flush changes back to the directory, we must commit the changes using the CommitChanges method. Note that if RefreshCache is called explicitly, or because another operation triggers the cache to be refreshed, any uncommitted changes will be lost. We have seen developers spin their wheels for hours on this problem because they accessed the Guid property before flushing changes in order to do some simple logging and kept magically erasing all of their changes. It looked like CommitChanges was doing nothing. Do not let this happen to you!

LDAP Data Types in NET