Folks, We (Supun, Indika, Udayanga and myself) had an off-line chat on this and we have decided to start with refactoring the existing caching capability and trying to improve it.
Ruwan On Mon, Jan 10, 2011 at 12:20 PM, indika kumara <[email protected]>wrote: > Udayanga, if you are going to implement a cache, please have a look at the > 'Caching Application Block'[1]'. Furthermore, have a look at the .Net cache > architecture (or any other research). Also you may use wso2's cache > implementation with or without modifications. Re-usability is key as the > cache is applicable in many contexts. > > Thanks, > > Indika > > [1] http://msdn.microsoft.com/en-us/library/ff664753%28v=PandP.50%29.aspx > > > On Mon, Jan 10, 2011 at 12:31 PM, Supun Kamburugamuva > <[email protected]>wrote: > >> I think cache is not something a user should think in terms of >> mediation. So I'm thinking that it should go in to a separate file. >> Only the people who write code will see the cache. >> >> This lead us to think about the Registry definition in the synapse.xml >> as well. The registry definition that is in the synapse.xml is not >> related to mediation as well. It is a static configuration that is >> ideally put in a separate file. >> >> Thanks, >> Supun.. >> >> On Mon, Jan 10, 2011 at 11:53 AM, Ruwan Linton <[email protected]> >> wrote: >> > Also you have neglected my question on the relation to the configuration >> > language with this, or are you planning to make this completely >> transparent >> > from the user? >> > Ruwan >> > >> > On Mon, Jan 10, 2011 at 11:52 AM, Ruwan Linton <[email protected]> >> > wrote: >> >> >> >> >> >> On Mon, Jan 10, 2011 at 11:35 AM, Udayanga Wickramasinghe >> >> <[email protected]> wrote: >> >>> >> >>> Hi Ruwan, >> >>> >> >>> On Mon, Jan 10, 2011 at 10:32 AM, Ruwan Linton < >> [email protected]> >> >>> wrote: >> >>>> >> >>>> Udayanga, may I know some usecases for this cache implementation?? >> >>>> Synapse is not designed for the users to interact with the API >> directly. It >> >>>> has a configuration language to access the API (in most of the cases, >> apart >> >>>> from the Class mediator and so forth, and the class mediator has to >> be your >> >>>> last option). >> >>> >> >>> One of the use cases is implementing a prefetcher. We can define a >> >>> prefetching criteria under cache so that certain entries(ie:-xslt,wsdl >> , >> >>> etc) are prefetched and cached upfront to enhance performance. So at >> runtime >> >>> remote entries/item collections could be prefetched from cache , >> without >> >>> contacting the registry first(otherwise first query would always be to >> a >> >>> remote reg) .Also whenever remote reg is down we can query prefetched >> cache >> >>> instead (and can easily employee a back-off criteria depending on the >> >>> window of failure ) . Another use case may be implementing a >> distributed >> >>> cache when multiple registry/esb instances are running . Implementing >> these >> >>> scenarios under current context tis hard because of the reasons i have >> >>> mentioned earlier. >> >> >> >> I don't think you need a separate cache to implement pre-detching?? We >> >> already cache the remote registry entries at the Configuration, >> implementing >> >> pre-fetching is just a matter of time at which you make the first call, >> >> isn't it?? it is just a switch required to check whether you want to >> work >> >> from the local cache when the remote registry is down, and continue >> using >> >> the local cache. This can be simply implemented with the existing >> context >> >> :-( >> >> How do you implement a distributed cache? what is the replication >> >> mechanism that you are planning to use, we do replicate stuff with >> Axis2 >> >> clustering implementation already. >> >> Thanks, >> >> Ruwan >> >> >> >>> >> >>> Regards, >> >>> Udayanga >> >>> >> >>> >> >>> -- >> >>> Udayanga Wickramasinghe >> >>> Software Engineer; WSO2 Inc.; http://wso2.com, >> >>> email: [email protected] cell: +94 (77) 983-4365 >> >>> blog: http://udayangawiki.blogspot.com >> >>> twitter: http://twitter.com/udayanga_wick >> >>> >> >> >> >> >> >> >> >> -- >> >> Ruwan Linton >> >> Software Architect & Product Manager >> >> WSO2 Inc.; http://wso2.org >> >> >> >> Lean . Enterprise . Middleware >> >> >> >> phone: +1 408 754 7388 ext 51789 >> >> email: [email protected]; cell: +94 77 341 3097 >> >> blog: http://blog.ruwan.org >> >> linkedin: http://www.linkedin.com/in/ruwanlinton >> >> google: http://www.google.com/profiles/ruwan.linton >> >> tweet: http://twitter.com/ruwanlinton >> > >> > >> > >> > -- >> > Ruwan Linton >> > Software Architect & Product Manager >> > WSO2 Inc.; http://wso2.org >> > >> > Lean . Enterprise . Middleware >> > >> > phone: +1 408 754 7388 ext 51789 >> > email: [email protected]; cell: +94 77 341 3097 >> > blog: http://blog.ruwan.org >> > linkedin: http://www.linkedin.com/in/ruwanlinton >> > google: http://www.google.com/profiles/ruwan.linton >> > tweet: http://twitter.com/ruwanlinton >> > >> >> >> >> -- >> Technical Lead, WSO2 Inc >> http://wso2.org >> supunk.blogspot.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > -- Ruwan Linton Software Architect & Product Manager WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: [email protected]; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
