Hi IsuruH/Pradeep, Great! A name value pair/property model would work in that sense.
Thanks Imesh On Mon, Jan 6, 2014 at 9:26 AM, Pradeep Fernando <[email protected]>wrote: > Hi Imesh, > > Thats why we thought of following RXT/property model. The data will be > decoupled from the application. > > --Pradeep > > > On Sun, Jan 5, 2014 at 7:50 PM, Imesh Gunaratne <[email protected]> wrote: > >> +1 A great thought Isuru. One question: >> In your proposal are you planning to store the data model as serialized >> objects in the Registry? >> >> If so will it be possible to change the data model at some point and >> upgrade an existing Stratos Manager instance to the latest without loosing >> data? >> >> Thanks >> >> >> On Sun, Jan 5, 2014 at 8:26 AM, Lahiru Sandaruwan <[email protected]>wrote: >> >>> +1 since this will avoid the burden of managing a DB / scripts for that. >>> >>> We may add distributed caching to our road map. May be using Hazelcast >>> after we finished the migration to Carbon 4.2.0... >>> >>> Thanks. >>> >>> >>> On Sat, Jan 4, 2014 at 8:12 PM, Isuru Haththotuwa <[email protected]>wrote: >>> >>>> Hi Kishanthan, >>>> >>>> Currently this is not a distributed cache. Stratos Manager, in which we >>>> store this information is not clustered at the moment. We will have to >>>> consider the distributed model once Stratos Manager is clustered. >>>> >>>> >>>> >>>> On Sat, Jan 4, 2014 at 11:46 AM, Kishanthan Thangarajah < >>>> [email protected]> wrote: >>>> >>>>> Hi Isuru, >>>>> >>>>> Is this a distributed cache model? >>>>> >>>>> >>>>> >>>>> On Tue, Dec 31, 2013 at 7:21 PM, Isuru Haththotuwa <[email protected]> >>>>> wrote: >>>>> > >>>>> > Hi Devs, >>>>> > >>>>> > To persist Subscription information given by a user at the time of >>>>> cartridge a subscription, we can use a Registry. Subscription information >>>>> are not dynamic, they do not regularly change. However, these data might >>>>> be >>>>> required at runtime for various operations. By using a registry, we can >>>>> store the subscription details as a Resource, and access it when required. >>>>> > >>>>> > However, one pitfall this approach can have is accessing registry >>>>> being relatively expensive. So, if we access the Registry frequently in >>>>> runtime, it would lead to a performance degradation. Therefore, I thought >>>>> to use an in-memory cache so that we don't have to access the registry >>>>> each >>>>> and every time we need to access some information. The idea is to populate >>>>> the cache when required, and in runtime avoid accessing the registry, and >>>>> use the cached data. >>>>> > >>>>> > I have included a very high level diagram of the proposed solution. >>>>> Please share your feedback. >>>>> > >>>>> > >>>>> > The scenarios would be: >>>>> > >>>>> > 1. We populate the cache when required (startup time / tenant >>>>> loading time), with any existing Subscription details >>>>> > 2. Subsequent retrievals are catered to with the cached information >>>>> > 3 & 4. Any changes (very infrequent) or new Subscriptions would be >>>>> updated in the cache first, and then the Registry. Ideally, updating the >>>>> registry should be a non-blocking call. >>>>> > >>>>> > -- >>>>> > Thanks and Regards, >>>>> > >>>>> > Isuru H. >>>>> > Software Engineer, WSO2 Inc. >>>>> > +94 716 358 048 >>>>> > >>>>> > >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> >>>> Isuru H. >>>> Software Engineer, WSO2 Inc. >>>> +94 716 358 048* <http://wso2.com/>* >>>> >>>> >>>> >>> >>> >>> -- >>> -- >>> Lahiru Sandaruwan >>> Software Engineer, >>> Platform Technologies, >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> email: [email protected] cell: (+94) 773 325 954 >>> blog: http://lahiruwrites.blogspot.com/ >>> twitter: http://twitter.com/lahirus >>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >>> >>> >> > > > -- > Pradeep Fernando. > http://pradeepfernando.blogspot.com/ >
