Hi all,
The RXT configuration is loaded just like any other registry resource. The
same caching principals work for it. Are we trying to solve another problem
here? Or did something actually break how registry caching works?
Thanks,
Senaka.
On Tue, Sep 16, 2014 at 7:25 AM, Pulasthi Supun
Hi Azeez,
Yes that can be done, that would reduce the number of DB calls further. We
can simply keep an entry for each RXT type that will keep a parity bit as a
value. Once a update is done the listener can query the exact RXT type that
was changed and only load that value.
Regards,
Pulasthi
On
Hi All,
Currently when working with RXT's each time the loadGovernanceArtifacts
method is called it in turn will call the DB to load the RXT's, this is to
load any changes done to the RXT's . This a major performance hit
especially in APIM since when loadGovernanceArtifacts is called multiple
For this type of problem, caching coupled with loading only the changed
parts is the way to go.
On Tue, Sep 16, 2014 at 10:53 AM, Pulasthi Supun pulas...@wso2.com wrote:
Hi All,
Currently when working with RXT's each time the loadGovernanceArtifacts
method is called it in turn will call the
On Tue, Sep 16, 2014 at 11:28 AM, Pulasthi Supun pulas...@wso2.com wrote:
Hi Azeez,
Yes that can be done, that would reduce the number of DB calls further.
We can simply keep an entry for each RXT type that will keep a parity bit
as a value. Once a update is done the listener can query the
Hi Shariq,
Yes that is why we are using the cache. the cache will be distributed. When
node 1 changes the RXT it will flip the parity bit in the cache entry that
correspondence to the changed RXT, then the listener will be called in node
2 since the entry was changed. And within the listener the
Yes, Will be using the listener API provided in the javax.cache
Regards,
Pulasthi
On Tue, Sep 16, 2014 at 11:53 AM, Afkham Azeez az...@wso2.com wrote:
I presume you are using the listener API provided by javax.cache.
On Tue, Sep 16, 2014 at 11:47 AM, Pulasthi Supun pulas...@wso2.com
wrote:
On Tue, Sep 16, 2014 at 11:47 AM, Pulasthi Supun pulas...@wso2.com wrote:
Hi Shariq,
Yes that is why we are using the cache. the cache will be distributed.
When node 1 changes the RXT it will flip the parity bit in the cache entry
that correspondence to the changed RXT, then the listener
Hi Senka,
Even though the RXT configuration file it self is cached in the resource
cache. everytime load artifacts is called it will first do a db call to get
all the RXT types which in turn results in several more DB calls as it
seems. So we are trying to altogether stop DB calls from happening
I presume you are using the listener API provided by javax.cache.
On Tue, Sep 16, 2014 at 11:47 AM, Pulasthi Supun pulas...@wso2.com wrote:
Hi Shariq,
Yes that is why we are using the cache. the cache will be distributed.
When node 1 changes the RXT it will flip the parity bit in the cache
10 matches
Mail list logo
