IN FOCUSMLDAP rule-set caching targets authorization work that ordinary result caching misses
MLDAP has two related but distinct caches. Its established LDAP search-result cache stores successful search results—including empty results—for reuse. Version 12.0 adds rule-set caching, which stores the internal access-control structures constructed from microfocus-MFDS-Resource objects. Consequently, it can avoid both repeated LDAP searches returning large result sets and the CPU cost of parsing those responses and reconstructing rules. MLDAP ESM Module Caching [1]
Read the full briefing
Scope: Rocket Enterprise Developer/Enterprise Server 12.0 for Eclipse on Linux/UNIX. Rule-set caching is new in Enterprise Server 12.0 and applies to Security Managers using the MLDAP ESM Module.
MLDAP has two related but distinct caches. Its established LDAP search-result cache stores successful search results—including empty results—for reuse. Version 12.0 adds rule-set caching, which stores the internal access-control structures constructed from microfocus-MFDS-Resource objects. Consequently, it can avoid both repeated LDAP searches returning large result sets and the CPU cost of parsing those responses and reconstructing rules. MLDAP ESM Module Caching
Rocket identifies JCL as a particularly useful case. Job and spool authorization requests often contain a job number in the resource name, making individual requests unique and limiting the usefulness of the normal ESF result cache. Rule-set caching operates at the reusable rule representation instead, so those unique requests can still avoid repeated rule retrieval and construction. MLDAP ESM Module Caching
Rule-set caching is disabled by default. Enable it in the MLDAP Security Manager’s Configuration Information:
[Cache]
rule sets=yesThe normal Cache Limit and Cache TTL settings govern the cache. Rocket recommends a Cache Limit of at least 1024 KB when rule-set caching is enabled; this is substantially larger than its general starting point of 16 KB for ordinary LDAP caching. Rule-set sizes depend on rule-name and access-control-list lengths, so Rocket provides no formula for calculating an optimum. It recommends using the cache-performance information logged when the Enterprise Server region shuts down and notes that a longer TTL might be needed to obtain the full benefit. Enabling and Configuring MLDAP ESM Module Caching
TTL is also the security-consistency boundary. A higher value improves reuse—especially in less-active service execution processes—but lengthens the possible period during which outdated LDAP security information can be used. Rocket therefore says to align TTL with the organization’s tolerance for delayed recognition of security changes. An ESF Update request flushes the MLDAP cache and reduces this exposure. MLDAP ESM Module
A crucial operational nuance is that caches are private to each Security Manager and process; only threads inside one process share a cache. MLDAP uses caching for Verify and Auth requests, while ESF Admin requests and certain schema or connection-validity searches bypass it. Entries can disappear through TTL expiration, least-recently-used eviction, automatic staleness marking, or an ESF Update flush. Understanding LDAP Caching
Takeaway: Enable rule-set caching for authorization-heavy workloads such as JCL, but size it per process and treat TTL as an explicit tradeoff between performance and how quickly LDAP security changes become effective.