There is a bit of a tradeoff with caching data close to the application. On one hand, the data is closer to the application BUT requires more memory on the client side. As soon as you enable caching proxy, all objects fetched or stored by that client are cached locally. As soon as you cache data, several challenges arise:
1. Memory management - how do you manage the objects on the client side so you don't run out of memory? Several options exist, including configuring expiration or configuring eviction 2. Risk of object becoming stale - when the object is cached on the client, there is a risk that changes on the server could make the local object stale. To address this, you could register interest in specific objects such that any server changes get pushed to the client asynchronously, ensuring your local cache is kept up to date Both of these issues and their solutions introduce an extra degree of complexity to the client. It may be that in some cases, this isn't worth the performance gains obtained by eliminating that extra network hop. In terms of your last question, the update of an entry (via put) results is a complete write to the server. Depending on the region type and configuration settings, full replication to all copies on the server may take place before an acknowledgment is returned to the client. In essence, you will know if something like this goes wrong and can take appropriate actions on the client. On Sat, Oct 21, 2017 at 3:22 PM, Xu, Nan <[email protected]> wrote: > Hi, > > > > Trying to get more understanding on client region caching_proxy vs > proxy. The caching_proxy seems is much more performant since it has a > local cache. And it also sync with server cache every time it see a change. > So in which scenario I need to use proxy instead of caching_proxy? Sounds > like I always want to use caching_proxy. Is that because cache proxy has > slight chance lose data when local update commit but not sync to server yet > and at this particular point. The client region crashes and losing the data? > > > > Thanks, > > Nan > > > ------------------------------ > This message, and any attachments, is for the intended recipient(s) only, > may contain information that is privileged, confidential and/or proprietary > and subject to important terms and conditions available at > http://www.bankofamerica.com/emaildisclaimer. If you are not the intended > recipient, please delete this message. > -- *Mark Secrist | Director, **Global Education Delivery* [email protected] 970.214.4567 Mobile *pivotal.io <http://www.pivotal.io/>* Follow Us: Twitter <http://www.twitter.com/pivotal> | LinkedIn <http://www.linkedin.com/company/pivotalsoftware> | Facebook <http://www.facebook.com/pivotalsoftware> | YouTube <http://www.youtube.com/gopivotal> | Google+ <https://plus.google.com/105320112436428794490>
