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/
