This article intend to share with you about a complex subject, OpenAM caching mechanism and persistent search.
1) OpenAM Caches
OpenAM comes with 2 caches:
- IDRepo Cache
- Service Management Cache
By default, those both active are active, when nothing else has been specified.
2) Flags that allows to tune caches
Tuning is provided using 3 flags:
The flag com.iplanet.am.sdk.caching.enabled allow enables global caching for both caches (i.e when set both caches area active)
It is possible to selectively set/unset each of the both caches using:
- com.sun.identity.idm.cache.enabled: used for IdRepo Caching
- com.sun.identity.sm.cache.enabled: Used for Service Management Cache.
3) What is Persistent Search
Persistent Search is defined by the RFC Persistent Search: A Simple LDAP Change Notification Mechanism.
When available, it provides the following OID supported Control Type 2.16.840.1.1137188.8.131.52
4) Persistent Search and Caching
A persistent search is an
ldapsearch which remains open even after the initial search results are returned.
Persistent search allows to send asynchronous notification event to the upper layer.
It means for example that when persistent search mechanism is in place, any update done at directory level will hence propagated at upper level.
In the case of openAM, it means that openAM caches will also get updated with any directory updates, when directory is implementing the psearch mechanism/functionality.
At openAM level, it is necessary to have cache coherency. Hence if the underlying product does not implement persistent search caching, the corresponding cache should be disabled.
Products implementing persistent searches are for example ODSEE, openDJ, OUD (and others). But in contrario openLDAP does not implement persistent search.
Below is an example of cache tuning where the data store, does not implement persistent search such as opendlap
Idm cache has been set to false, whereas SM cache (Service Management Cache) is set to true
5) additional pointers