On Fri, Jul 20, 2012 at 2:17 PM, Tharindu Mathew <[email protected]> wrote:
> Alright, so it worked earlier cus caching was not there at the registry > API level? Yes Tharindu you are quite right. Earlier (may be in our internship period time ;-) ) greg did not have registry API level caching and now registry calls intercepted by a registry called CacheBackedRegistry. And those days as there is no cache, no need replicated caching enabled as both ends directly deals with the DBs. > > > On Fri, Jul 20, 2012 at 2:14 PM, Subash Chaturanga <[email protected]>wrote: > >> >> >> On Fri, Jul 20, 2012 at 1:19 PM, Tharindu Mathew <[email protected]>wrote: >> >>> There is no ESB cluster here. Only an ESB connecting to G-Reg. I believe >>> for this scenario, replicated caching is not needed? >> >> Yes, I also didn't meant ESB cluster(may be I have not communicated it >> ;-) ). I am also talking about a typical mounted scenario, i.e 1 esb, 1 >> greg, esb gov mounted to greg gov and etc. And AFAIU the scenario I >> explained is valid for such mounts. >> >> >> >>> >>> >>> On Fri, Jul 20, 2012 at 12:36 PM, Subash Chaturanga <[email protected]>wrote: >>> >>>> >>>> >>>> On Fri, Jul 20, 2012 at 10:36 AM, Tharindu Mathew <[email protected]>wrote: >>>> >>>>> Subash, >>>>> >>>>> Can I know why this is needed? This was not required earlier so I'd >>>>> like to understand why it's needed now? >>>>> >>>> >>>> Hi Tharidu, >>>> I hope you meant why caching a must for jdbc mounting. I am not sure >>>> why this didn't wanted earlier. >>>> >>>> In caching of carbon clusters, each carbon instance has its own cache. >>>> Assume replicated caching not enabled. >>>> >>>> So suppose a two node cluster which has jdbc mount. When do a update on >>>> one carbon instance and it clears the cache and persist the >>>> change(delete/put) to the DB. The problem comes when some other node do a >>>> *get* from the same earlier changed location. Because its cache not >>>> updated. Unless you do a put on the same location and clears the cache you >>>> will not see the changes. If replicated caching enabled, infinispan does >>>> the sync between two caches. >>>> >>>> >>>> Hi Charitha, >>>> In fact this is a MUST for atom/ws as well IF you need 100% consistency >>>> across the cluster. Because there are some edge cases. >>>> It works fine until you do changes from the mounted side. If you do >>>> some changes on the other side(master), the changes not get reflected. I >>>> hope you got what I meant. >>>> >>>> >>>> >>>>> >>>>> >>>>> On Fri, Jul 20, 2012 at 9:49 AM, Charitha Kankanamge < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks Subash, this is something we have not documented anywhere. We >>>>>> should update all docs, blogs with this information. >>>>>> >>>>>> >>>>>> On Friday, July 20, 2012, Subash Chaturanga wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 19, 2012 at 11:48 PM, Charitha Kankanamge < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Folks, >>>>>>>> Should replicated caching be enabled with registry mounting? >>>>>>>> Suppose /_system/governance space of an ESB instance is mounted (jdbc >>>>>>>> or >>>>>>>> ws) to the same collection of a central G-reg. In that case, should we >>>>>>>> enable replicated caching in both ESB and G-reg instances? >>>>>>>> Please confirm. >>>>>>>> >>>>>>> Hi Charitha, >>>>>>> Yes, for JDBC mounting it is a MUST. But AFAIK, for atom/ws mounting >>>>>>> it should be fine without replicated caching enabled. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Charitha >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Subash Chaturanga >>>>>>> Software Engineer >>>>>>> WSO2 Inc. http://wso2.com >>>>>>> >>>>>>> email - [email protected] >>>>>>> phone - 077 2225922 >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Charitha Kankanamge >>>>>> cell: +94 718 359 265 >>>>>> blog: http://charithaka.blogspot.com <http://wso2.com> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Tharindu >>>>> >>>>> blog: http://mackiemathew.com/ >>>>> M: +94777759908 >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Subash Chaturanga >>>> Software Engineer >>>> WSO2 Inc. http://wso2.com >>>> >>>> email - [email protected] >>>> phone - 077 2225922 >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> Tharindu >>> >>> blog: http://mackiemathew.com/ >>> M: +94777759908 >>> >>> >> >> >> -- >> >> Subash Chaturanga >> Software Engineer >> WSO2 Inc. http://wso2.com >> >> email - [email protected] >> phone - 077 2225922 >> >> > > > -- > Regards, > > Tharindu > > blog: http://mackiemathew.com/ > M: +94777759908 > > -- Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - [email protected] phone - 077 2225922
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
