Caching in OpenAM
The two primary caches in OpenAM are for configuration data and user data, known as SMS and IdRepo respectively. The OpenAM admin has some control over how these caches behave, described below.
This property controls whether caching is enabled for both cache types and is set to true by default. If this is set to false then both caches may be disabled (see below) and a new query will be issued to the data store whenever data is needed. This can cause severe performance degradation in large deployments and should be used with caution.
If the property com.iplanet.am.sdk.caching.enabled is true then this property is ignored. If com.iplanet.am.sdk.caching.enabled is false then this property determines whether the IdRepo cache is enabled.
If the property com.iplanet.am.sdk.caching.enabled is true then this property is ignored. If com.iplanet.am.sdk.caching.enabled is false then this property determines whether the SMS cache is enabled.
If you wanted to only enable the IdRepo cache then you would set:
If you wanted to only enable the SMS cache then you would set:
If you wanted to disable both the IdRepo and SMS cache then you would set:
The size of the IdRepo cache may be adjusted with this property. By default this cache will contain up to 10,000 entries. Note that there is no equivalent property to control the size of the SMS cache.
These properties control whether the IdRepo cache will expire entries based on time-to-live and how old entries may get before expiring. By default the enabled property is False and the expire.time is 30 (the latter is expressed in minutes).
These properties control whether the SMS cache will expire entries based on time-to-live and set the maximum time-to-live value. By default these properties are false and 30 minutes respectively. The TTL value is expressed in minutes.
In busy systems significant performance gains can be achieved by extending these time-to-live values but this must be balanced against the change rate of the underlying data. User data (IdRepo cache) typically changes at a much higher rate than OpenAM configuration data so the IdRepo TTL should be kept relatively low while SMS TTL may be much higher.
The cache invalidates entries via 3 possible mechanisms: TTL, Notifications or Polling. With TTL invalidation entries will "expire" and require a refresh after their TTL times have elapsed since the last refresh. TTL invalidation may be used in conjunction with Notifications or Polling though Notifications and Polling may not be used together.
Notifications can only be sent is OpenAM is aware of the changes. To ensure OpenAM is made aware of all such changes persistent search should be enabled:
Set this property to true to enable notifications for SMS data changes and remove "sm" from the disable.list property.
To enable notifications (which are sent any time data is changed) the following properties must be set:
Set enabled to true and set the url property to the notification endpoint that will receive the notifications and determine when to expire the SMS cache. Note that the url property is shared with the IdRepo cache notifications.
The com.sun.identity.client.notification.url property should be set to http://host.domain/openam/notificationservice where the host, domain (and port) identify the server hosting the ClientSDK, "openam" is the name of the deployed application and "notificationservice" remains as-is.
If you prefer to poll for changed data rather than use notifications, set the following properties:
Set notification.enabled to false and set pollingTime to the poll frequency in minutes to enable polling for the IdRepo cache.