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
time
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 w
I presume you are using the listener API provided by javax.cache.
On Tue, Sep 16, 2014 at 11:47 AM, Pulasthi Supun 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 co
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 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 exact RXT type that
was changed and only load that value.
Regards,
Pulasthi
On
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 wrote:
> 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
On Tue, Sep 16, 2014 at 11:28 AM, Pulasthi Supun 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 exact RXT
> ty
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 c
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 wrote:
> I presume you are using the listener API provided by javax.cache.
>
> On Tue, Sep 16, 2014 at 11:47 AM, Pulasthi Supun
> wrote:
>
>> Hi Shariq,
>>
>> Yes th
On Tue, Sep 16, 2014 at 11:47 AM, Pulasthi Supun 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 will be called
>
Hi All,
This was added to 4.3.0 [1]
[1] https://wso2.org/jira/browse/REGISTRY-2301
Regards,
Pulasthi
On Tue, Sep 16, 2014 at 3:13 PM, Pulasthi Supun wrote:
> Hi Senka,
>
> Even though the RXT configuration file it self is cached in the resource
> cache. everytime load artifacts is called it
11 matches
Mail list logo