curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <>
Subject Re: cache recipes
Date Thu, 17 Nov 2016 22:58:31 GMT
Hey Scott,
This would mean blocking the main thread until the event arrives though yes?

I think that Hendrik was taking about having the cache updated as soon as
the write is acknowledged by ZK, rather than waiting for the watcher to

On 18 Nov 2016 9:47 AM, "Scott Blum" <> wrote:

> You can also just listen for TreeCache events and wait for your change to
> come through.
> On Thu, Nov 17, 2016 at 3:18 PM, Hendrik Haddorp <>
> wrote:
>> Thanks, that was a pretty fast answer! Not quite what I had hoped for but
>> at least now I know that I was right that I have to handle this myself :-)
>> On 17.11.2016 21:13, Cameron McKenzie wrote:
>> Hey Hendrick,
>> The recipes don't treat local updates any differently to remote updates.
>> The cache will get updated when the cursor client receives a watch event
>> from Zookeeper.
>> So your assertions are correct. The caches provide eventual consistency.
>> If you need to ensure that there are no dirty reads between when you write
>> locally and when you read from the cache you would need to wrap the cache
>> in some manner.
>> Cheers
>> On 18 Nov 2016 7:06 AM, "Hendrik Haddorp" <>
>> wrote:
>>> Hi,
>>> I'm trying to use a cache recipe, like the TreeCache. The cache itself
>>> works just fine but what I don't understand is how I'm supposed to handle
>>> locally triggered updates correctly. I can start the TreeCache and using
>>> the events I know when it is initialized but what if I delete a child node
>>> or update a node for example? If I read the data out of the cache before I
>>> get the corresponding update events I get old data. As there doesn't seem
>>> to be an invalidation mechanism I seem to be required to track outstanding
>>> updates. Or am I missing something?
>>> regards,
>>> Hendrik

View raw message