Is there a way to programmatically clear a service cache

, ,
1

I’ve read a bunch of stuff on issue with caching, and I’m only caching those services called as transformers, but I’m wondering if anyone knows a way to clear the cache of a service from another flow service?

I am building a 10 mb data file with a lot of data lookups… I want them to be cached for each execution of the service, but cleared when the process starts.

I’ve looked all over the forums here and on advantage, without much luck… any help would be appreciated

2

well… no sooner did I post this message, then did I find a way to do it… I looked at the code for the admin page WmRoot/pub/stats-services.dsp (where you can reset the cache) and saw that it was invoking the service:
wm.server.cache.adminui:resetCache
which of course, cannot be browsed to from developer (which is why I had trouble finding it… :wink:
and invoking the service seems to do the job… as I can’t see the signature of the service, I don’t know if you can selectively pick which services are cleared, but it clears all, and I currently only have a few cached…

3

Hello Dan,

Instead of ‘wm.server.cache.adminui:resetCache’ use the service

wm.server.cache:resetCache

This service takes the service name as parameter and clears the cache.

  • Rajesh Rao
4

Dan - I recently asked WM this question a couple of weeks ago and they gave me the same answer as Rajesh. I’ve tried the wm.server.cache:resetCache service and it works.

IMPORTANT: A caching services restores the PIPELINE (not the output ) from it’s first invocation. Since IS “blends” pipelines when calling a service, make sure you do a clearPipeline as the first step of your cached service (with the ‘preserve’ input set to the inputs you use in your service). Otherwise you may hit all sorts of wierd caching effects due to variable name clashes.

5

Sonam,
I agree that you need to be very careful when dealing with cached services due to the pipeline management issues you noted. However, it can be a bit risky to use clearPipeline in a low-level/embedded/utility service if you’re not entirely aware of the calling service’s pipeline requirements. You could easily end up removing things from the pipeline upon which the calling service will later rely.

For this reason, my preferred approach for using cached services is to ensure the pipeline is properly scoped when I call the service. There appear to be two ways to do this (as discussed in a separate thread). Either use the Scope field on the Properties tab of the Flow step that calls the service, or call the service as a transformer.

I prefer to call cached services as transformers since the Scope field appears somewhat constrained. You have to manually specify a “document” that gets passed to the service in the Scope field, and I don’t think that provides enough control over the pipeline to be effective in many situations. On the other hand, Transformers automatically scope the pipeline to the declared Input of the cached service.

Overall, I’d like to see webMethods improve in this area. In my (albeit limited) experience, the 80/20 rule would be better served by caching ONLY the Output of a service. An option to control this behavior (cache entire pipeline), would then be a bonus.

6

Mike - You said:

“it can be a bit risky to use clearPipeline in a low-level/embedded/utility service if you’re not entirely aware of the calling service’s pipeline requirements.You could easily end up removing things from the pipeline upon which the calling service will later rely.”

If I recall correctly, a clear pipeline isn’t risky since it only clears the references to “unwanted” variables in the local pipeline - the calling service still retains the references.

i.e. If the called service does a clearPipeline, even though it cannot access the cleared variables, the calling service can access the “cleared” variables when control returns to it.

A simple test I did with 2 services backs this:

Service cl1 calls cl2.

Here is the chain of execution:
cl1 sets variable ‘aa’ to ‘123’
cl1 now calls cl2
(control transfers to service cl2, which can refer to variable aa)
cl2 clears pipeline
(cl2 can no longer refer to variable aa)
cl2 returns control to cl1
cl1 can access variable ‘aa’ whose value is ‘123’

Regards,
Sonam

7

Aah, I see. Thanks for clearing that up Sonam. Awfully clever with that clearPipeline weren’t they? :slight_smile: You know, I was probably told that at some point in the past, but some things just don’t click until they hit home, ey?

8

Glad to help Mike. In fact, thank you - I wasn’t a 100% sure until I did the test.

9

Sonam,

Thanks for your “Wednesday, October 08, 2003 - 01:49 am” post. It helps clear up some things for me.

So if A=Calling Service & B=Called Service

  1. A’s pipeline is intact before and after call to B (irrespective of whether B dropped some of A’s original variables).
  2. If B dropped some of A’s variables, B will ofcourse not have further access to these variables.
  3. If B created some new variables, A will have access to this after return from B.

I guess this is what you refer to as “blending” of pipelines.

10

Wow, another old post mentioned recently .

That’s right Will; that’s what I meant by blending.