Understanding the ADSI Property Cache

Table of contents:

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

Part I: Fundamentals

Introduction to LDAP and Active Directory

Introduction to .NET Directory Services Programming

Binding and CRUD Operations with DirectoryEntry

Searching with the DirectorySearcher

Advanced LDAP Searches

Reading and Writing LDAP Attributes

Active Directory and ADAM Schema

Security in Directory Services Programming

Introduction to the ActiveDirectory Namespace

Part II: Practical Applications

User Management

Group Management


Part III: Appendixes

Appendix A. Three Approaches to COM Interop with ADSI

Appendix B. LDAP Tools for Programmers

Appendix C. Troubleshooting and Help


The. NET Developer's Guide to Directory Services Programming
The .NET Developers Guide to Directory Services Programming
ISBN: 0321350170
EAN: 2147483647
Year: 2004
Pages: 165

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net