On Thu, Sep 8, 2016 at 11:04 AM, Rushmin Fernando <[email protected]> wrote:
> Thanks for the responses. > > Yes we have thought about maintaining a cache. But then we have to write > code to invalidate / update the cache once an app is updated (@Imesh : > practically the frequency is very low) > > In order to reduce the complexity we can make this cache a not-distributed > one and update the cache from the gateway admin service call which is > already being invoked by the publisher. > > With the current implementation we don't have to worry about the updating > the web app info in the gateway since it happens automatically when a new > handler instance is created upon Synapse API re-deployment. > > Do we have a cache implementation to be used as a local cache ? > Can't we use our platform provided JCache impl as a local cache for this purpose ? > > Best Regards, > Rushmin > > On Mon, Aug 29, 2016 at 7:50 AM, Imesh Gunaratne <[email protected]> wrote: > >> On Tuesday, August 23, 2016, Chathura Ekanayake <[email protected]> >> wrote: >> >>> Hi Rushmin, >>> >>> Can't we maintain a cache of domain objects, may be in a data holder >>> instance? >>> >> >> Yes, using a cache with a data holder instance would be appropriate for >> this problem. Do we know how frequently these data sets get updated in the >> database? >> >> Thanks >> >> >>> BTW, what are the attributes of an example domain object (e.g. webapp >>> object)? >>> >>> - Chathura >>> >>> On Mon, Aug 22, 2016 at 11:54 AM, Rushmin Fernando <[email protected]> >>> wrote: >>> >>>> Hi Isuru, any comment on this ? :-) >>>> >>>> On Thu, Aug 18, 2016 at 10:54 AM, Rushmin Fernando <[email protected]> >>>> wrote: >>>> >>>>> It depends on the applications, users invoke Isuru. >>>>> >>>>> If users invoke all the apps then we end up fetching all the apps by >>>>> the handler instances for the apps (synapse APIs). ( A handler instance >>>>> only fetched and stores only one app instance) >>>>> >>>>> In the current implementation the fetch happens on demand. >>>>> >>>>> >>>>> On Thu, Aug 18, 2016 at 9:18 AM, Isuru Udana <[email protected]> wrote: >>>>> >>>>>> Hi Rushmin, >>>>>> >>>>>> Do we need to fetch domain objects from the database for all the >>>>>> applications or is it only for a set of applications ? >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 16, 2016 at 1:35 PM, Rushmin Fernando <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> In App Manager we use carbon mediation engine as the gateway. Thus >>>>>>> the business logic is implemented in few handlers. >>>>>>> >>>>>>> In order to code business logic, we need to fetch domain objects >>>>>>> from the database via a service. The primary domain object the "webapp' >>>>>>> object. >>>>>>> >>>>>>> (Please see the attached image) >>>>>>> >>>>>>> In the current implementation, we have made the webapp object, an >>>>>>> instance variable of the handlers. Since the handlers are instantiated >>>>>>> per >>>>>>> API (represents an app in our case), this works fine. >>>>>>> >>>>>>> Upon the first call to the app, we fetch the relevant webapp object >>>>>>> and store it as the aforementioned instance variable. >>>>>>> >>>>>>> Since there are more than one handlers which need to deal with the >>>>>>> webapp object we need to do above step in each of those handlers. >>>>>>> >>>>>>> We are thinking of having an init handler which does the service >>>>>>> call and fetch the domain object and share it with the other handlers in >>>>>>> the chain. The purspose of evaluating this is to, increase the code >>>>>>> maintainability and improve the performance to some extent. >>>>>>> >>>>>>> In order to do that we need to have the domain object in the message >>>>>>> context. But then again consume a lot of memory when there is a high >>>>>>> load. >>>>>>> >>>>>>> One solution to above issue to create a new thin domain object with >>>>>>> only the necessary fields for the gateway. >>>>>>> >>>>>>> Thoughts please ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Best Regards* >>>>>>> >>>>>>> *Rushmin Fernando* >>>>>>> *Technical Lead* >>>>>>> >>>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>>>> >>>>>>> mobile : +94772891266 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Isuru Udana* >>>>>> Technical Lead >>>>>> WSO2 Inc.; http://wso2.com >>>>>> email: [email protected] cell: +94 77 3791887 >>>>>> blog: http://mytecheye.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Best Regards* >>>>> >>>>> *Rushmin Fernando* >>>>> *Technical Lead* >>>>> >>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>> >>>>> mobile : +94772891266 >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Best Regards* >>>> >>>> *Rushmin Fernando* >>>> *Technical Lead* >>>> >>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>> >>>> mobile : +94772891266 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >> >> -- >> *Imesh Gunaratne* >> Software Architect >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: https://medium.com/@imesh TW: @imesh >> lean. enterprise. middleware >> >> >> > > > -- > *Best Regards* > > *Rushmin Fernando* > *Technical Lead* > > WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware > > mobile : +94772891266 > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
