Possible stale cache when using RunInTransaction with specific order of memache failure. about nds HOT 9 OPEN

Do you get an error or other notification that the memcache lock failed?

from nds.

There isn't an error. It's just that there is a very tiny possibility that nds.Get will return stale results from its cache after using nds.RunInTransaction if the sequence of events occur exactly as described above.

It's makes the difference of the nds package having complete cache consistency compared to strong cache consistency.

from nds.

If there isn't any way to know whether or not memcache failed in the way you describe, you could force a cache reload at the end of every RunInTransaction request.

from nds.

That would help a bit, but if the cache reload failed we would still end up with a stale cache. I am beginning to think the package as it is now, although not perfect, is the best possible situation.

from nds.

I don't have any issues with the possibility of that cache error. It seems very unlikely, and as the datastore is eventually consistent anyways, people should already be ready for the possibility of stale data.

from nds.

The Get, Put and Delete datastore calls are strongly consistent. Only queries without an ancestor are eventually consistent. I rely on those guarantees for the type of code I write - which is why it is taking me so long to get this package right. 😅

from nds.

What about adding FlushCache(key) / FlushCacheAll() functions so that you can eliminate keys in the event that you absolutely can't have stale results?

from nds.

What about a GetIgnoreCache?

from nds.

With NDS the datastore never has the opportunity to be populated with stale results. It will always be 100% intact. So if you really need to return 100% non stale results you could just use datastore.Get perfectly fine which would be the equivalent of the GetIgnoreCache you suggested.

from nds.