Hacker News Reader

You still have a race condition, as long as your backend serves more than one request at the time.

If you nuke the cache _before_ performing the change, another request might make the changed item reappear in the cache before the change is completed.

If you nuke the cache _after_ performing the change, requests might sneak in between the change and the cache nuke and get stale data.

View on HN

Caches seem to be much easier to handle using the actor model for handling concurrency.

Actors can have their own cache, and since they queue messages and handle them in order, one at a time, the cache will never be out of sync.

It does come at several other costs though.

Actors can indeed make caches super easy.

If your entries are simple enough (add/remove/update) and can be expressed as messages, wiring up a simple pub-sub cache is an afternoon project.

Then you should lock the cache while the change is being performed?

I'm not sure why you got downvoted. A lock could easily solve that problem. Specifically, you could use a read-write lock where readers either keep it open for an entire request or check an epoch number each time they take the lock and abort/restart the request if it changes.

Reply on news.ycombinator.com