Team,

we use ehcache on webMethods IS along with cacheloader in multiple ways (one method is to use with pub.cache:get and useLoader set to true).

Loader is written as a java program 

public class CountryCapitalCacheLoader implements CacheLoader {}

(not sure if there is another mechanism -- but that for some other day).

the loader needs to query DB and return vaule (and it gets autoamtically added to cache).

We implement DB query using JDBC Adapter. Now In order to invoke Adapter Service from CacheLoader it requires using Context long with URL/username /password (even when loader is running with IS's JVM).

Has anyone implemented something of this type? and what other mechanism have you used?

I am not going to question why you have used a java CacheLoader since that is a topic that you also wanted to stay away from. Surely you must have reasons.

But since you want to invoke a service, you do need to have a valid session in the Integration Server. You are in the IS but the code that is executing is pure java and doesn't have the Session/InvokeState information.

There are a few tricks you can use. You can either fire up a startup service that saves its InvokeState or Session information in some reference that your code can retrieve and use from. Or you could fire up the load process in the CacheLoader from the startup service itself. That way it will have an InvokeState and you can call any service in that context. 

Rupinder

public class CountryCapitalCacheLoader implements CacheLoader {}

Rupinder, 

From use case perspective: we are using Cache for cross references (e.g. Converting EA to Each, USA to US and so on). 

While 95% of these are static, our users can perform CRUD operation on cache entries. In such scenario - users can trigger a "clear cache".  Subsequent transactions' call to cache leads to cache loader getting called till entire cache is hydrated again.

We also have Xalan "extensions" built to be invoked in XSLT services that leverage these cache extensively.

The reason to use java cache loader is because - that is actually only mechanism available from ehcache/webMethods as part of this process (IBM/webMethods could provide a sample cache loader or a generic cache loader sample - but it doesn't exist currently). 

We can query DB Directly from Cache Loader (using JDBC Operation) - and that is one of the options we had used (Traditionally, this was based on JPA etc.). We are in process of making these frameworks lighter to keep containers smaller as well as reduce dependencies on non-webMethods code much as possible.

One of the process I have tried is invoking following directly:

We have been using Context pattern for a while (10y+), but that is requiring us to store username and password and access it within loader (Alternative would be to use X509). Mainly we are trying to identify a way to avoid storing and accessing credentials.

In the past I have used a credential file to get the username and password in Java client and pass it to context class for connection. Having said that there might be a way to do this without "storing" credentials on your (client) end by storing the user name and password as global variables on the IS (server) and then expose a web service back from IS to the client with basic auth to get the credentials from Global variables.

Or you could just use a X509 cert and pass it along for the IS auth.

But when looking at your use case, you could just use an Execute Service adapter service template and run the query and load the cache within a wM Java service.

Hi Chirag,

Based on what you outlined, the intent is to preserve the caller's user identity for auditing. The optimum solution (while keeping containers lightweight) is to - first we keep a startup service so that when pod restarts the cache and loader are ready, and warm-up time is less. Then we have a wrapper service which takes the current session whenever the cache check service (cache.get(key)) is called. This wrapper safely passes the session into the cache loader, and from there the loader calls the actual service using Service.doInvoke(...). This way everything works smooth, and user context is also preserved.