LDAP attribute cache

Edit online

You can use LDAP attribute cache to resolve search filters faster if the attributes requested in the search filter are cached.

Note: Starting from IBM® Verify Directory, version 6.3, attribute cache is deprecated. You must avoid configuring attribute cache.

The attribute cache stores configured attributes and their values in memory. When a one-level, subtree, or base search is run against a server, the server attempts to resolve the filter in memory by using the entry cache. If a filter cannot be resolved, the server uses the attribute cache manager to resolve the filter in memory if the following conditions are met:

  • All the attributes that are used in the filter are cached.
  • Filter type is supported by the attribute cache manager.

Resolving filters in memory improves the search performance over resolving filters in DB2®.

You can configure the attribute cache to store attributes. You can configure the attribute cache to automatically select the attributes that are expected to provide the most cache hits, see Configuring attribute caching. Alternatively, you can choose specific attributes to cache.

You can determine the attributes to store in the attribute cache by considering how the queries are resolved by the attribute cache.

Processing queries in the attribute cache
All attributes that are used in the search filter are cached if the filter type can be resolved by the attribute cache manager. If such cases, the list of matching entry IDs are resolved in memory by using the attribute cache manager. The list of matching IDs are then sent to the entry cache. The attribute cache is most efficient when you use it in combination with the entry cache.
Resolving simple filters in the attribute cache
The attribute cache manager can resolve simple filters of the following types:
  • Exact match filters
  • Presence filters
Resolving complex filters in the attribute cache
The attribute cache manager can also resolve complex filters that are conjunctive or disjunctive. The subfilters within complex filters must be exact match, presence, conjunctive, or disjunctive. The complex filters can of the following types:
  • Exact match filters
  • Presence filters
  • Conjunctive filters
  • Disjunctive filters
Processing language tags in the attribute cache
Filters containing attributes with language tags are not resolved by the attribute cache manager. For example, if the attributes objectclass, uid, and cn are cached, the following filters can be resolved in memory within the attribute cache manager:
  • (cn=Karla)
  • (cn=*)
  • (&(objectclass=eperson)(cn=Karla))
  • (&(objectclass=eperson)(cn=*)(uid=1234567))
  • (&(&(objectclass=eperson)(cn=*))(uid=1234567))
  • (&(uid=1234567)(&(objectclass=eperson)(cn=*)))

The attribute cache might not resolve the query for the following conditions:

  • Some or all of the attributes that are used in the search filter are not cached.
  • The filter type cannot be resolved by the attribute cache manager.

If there are no attributes in the attribute cache, the attribute cache manager sends the query to the filter cache to resolve. For example, if the attributes objectclass, uid, and cn are the only cached attributes, the following filters cannot be resolved in memory by the attribute cache manager:

  • (sn=Smith)
  • (cn=K*)
  • (|(objectclass=eperson)(cn~=Karla))
  • (&(objectclass=eperson)(cn=K*)(uid=1234567))
  • (&(&(objectclass=eperson)(cn<=Karla))(uid=1234567))
  • (&(uid=1234567)(&(objectclass=eperson)(sn=*)))
Note: Choosing to cache the member, uniquemember, or ibm-membergroup attributes can lead to reduced performance with the delete and modrdn operations. If you are deleting or renaming an entry that is a member of many groups, then the attribute caches must be updated. The update is required to reflect the change for every group in which the entry was a member.