How to OIM cache work

Source: https://abhirockzz.wordpress.com
Oracle IDM uses OSCache from the OpenSymphony project for in memory caching of objects in order to avoid repetitive calls to database and improve performance (of course !). In case you are not familiar with caching in general, I am pretty sure that as someone working on OIM, you would have executed PurgeCache.sh at some point in your career – so there it is ! If you have ever purged OIM’s cache, you have indirectly used OSCache.. yay !

How is it implemented ?

• OIM uses a facade/wrapper over the core OSCache caching APIs
• XLCacheProvider is essentially used as the generic interface which is implemented by a class called OSCacheProvider (this is OIM specific). You should be able to see an entry of this class in oim-config.xml (caching categories config section). It’s FQDN is oracle.iam.platform.utils.cache.OSCacheProvider
• This class implements the contract put forth in the XLCacheProvider interface and leverages internal OSCache APIs
• It caters to operations like adding to cache, removing entry from a cache, purging the entire cache etc. It also supports the notion of cache categories or groups. Sounds familiar ? The category is something which you provide as an input to PurgeCache script e.g. MetaData, User, Catalog, LookupValues etc. Please note that these are constant values and need to provided as it is

What categories of objects does OIM cache ?

Well there is lots, from adapters, to application instance details, resource bundles etc Actually, the list is pretty long 

How does OIM use this Cache ?

Pretty straightforward actually. The caching logic is implemented within the core server business logic itself and items from different categories (mentioned above) are explicitly pushed into the cache by calling the high level APIs e.g. look up related calls, user search details, MDS data etc (just the tip of the iceberg)

How much control/visibility do we have over the cache?

From what I know, not much apart from disabling/enabling the cache per category and configuring things like expiry time etc (all via oim-config.xml) and of course purging it 

From what I have observed, we cannot

• introspect the cache
• validate it contents
• confirm whether out favorite PurgeCache is in fact working 

Why ? Simply because it does not expose the internal interfaces of the OSCache API to us (figuring out how and why is left to you as homework) and as of now I am not aware of how to hook into an in memory OSCache instance (maybe its possible ?)

So that brings me to another question

Should we plug in our own caching implementation ?

Sounds risky doesn’t it ? Well that’s why I haven’t heard people doing it. But it should definitely be theoretically possible

• Provide a custom implementation of XLCacheProvider interface
• Package it as a JAR into APP-INF/lib folder within oim.ear (OIM_HOME/server/apps)
• change the provider attribute in the cacheConfig tag within oim-config.xml to reflect your custom implementation.

Some more thoughts

• If I decide to play with this, I’ll certainly opt for the JCache API [JSR 107] in order to implement this. At least this is a standard API !
• Maybe even expose cache metrics as read only attributes over a RESTful interface ? I think this should be useful (from a geeko-meter perspective !)