Flushing Cache via InvokeAction API

[Anon Anon]

The Clarity Integration Guide mentions that the clarity cache can be flushed via the InvokeAction API.    Below is the example from the guide on how to do that:          Resources  ConfigurationProperties       I want to build a  gel script  within a process which will flush the  Clarity cache on a regular basis (probably a proactive way to keep the system performance high). I however have a few questions about this functionality:  1) Will it flush the cache for the only  a particular app tree or does it flush the cache for all the apps? If I log in to a particular app tree and flush the cache via the URL, does it flush for that app tree or all the trees?  2) The above example, if I remove the group and the id tags, does it do the same action as the 'Flush All' button or the 'Flush Configuration' button?  3) What's the difference between Flush All and Flush Configuration? --> probably this had been answered in some other thread....a mention would be helpful.     Sankhadeep     

[Anon Anon]

I think the first and most important thing to note is the purpose of the caches.  Caches provide faster access to data by keeping it close at hand.  In Clarity's case, this data normally resides in the database.
 
Flushing the caches on a regular basis will not accomplish anything other than SLOWING down the performance of the application by forcing it to go back to db tier to refill the caches again.  I would strongly recommend against flushing the caches on a regular basis.
 
To answer your other questions:
 
1) Flushing caches causes a flush across the entire Clarity cluster, not just the application instance you are flushing the caches in.
 
2) Not certain without testing the behavior.
 
3) Flush All flushes ALL of the cache groups and the configuration (the application instances cached copy of properties.xml).  Flushing the configuration merely flushes the cached copy of properties.xml.  This latter flush is useful if you change something simple in the NSA such as LDAP configuration, SMTP mail server, Entry URL, etc..  Any values that are used at Java startup time will not be affected by a cache flush (such as Java arguments).
 
Sean

[Anon Anon]

Thanks for the guidance Sean. I had ignored the real purpose of caches.  As for point 2, according to  the XOG WSDL, there are 3 elements related to fushing caches. They are:  FlushCaches -- to be used when filtering for flushing particular cache group  or id.FlushAllCaches -- to be used when flushing all cache groups.FlushObjectCViews -- this has the element object with attributes code(which is the object code) and partitionCode. If I am not wrong, this does the same action as publishing Object Views from Clarity Studio.