All Curator caches have had that problem. I guess what's needed is a way to listen for writes so that the cache can subscribe. Or, add some kind of write semantics to the CuratorCache API?
-Jordan > On Jul 27, 2021, at 7:27 AM, Enrico Olivelli <[email protected]> wrote: > > Hello folks, > I was discussing with a colleague of mine, who is starting to use Curator > for a brand new project. > > I suggested using a CuratorCache in order to have a Cache over a subtree of > ZK as usual. > > I am missing some part of the story. > > If I use a CuratorCache and I update a znode, then I am not guaranteed to > immediately see the result of my write reflected into the local > CuratorCache, because the Cache will be only eventually updated with the > new value. > So I cannot implement "read-my-writes" semantics.... > > Shall we add some "write-through" API to CuratorCache ? or add some > plumbing in CuratorClient in a way that the writes using the client are > automatically applied to every CuratorCache registered in the Client ? > > > Best regards > Enrico
