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:

public class CountryCapitalCacheLoader implements CacheLoader {}