4 ms·
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, anothe
by gnud 6y ago
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.
- undreren 6y agoCaches 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.
- csharptwdec19 6y agoActors 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.
- gberger 6y agoThen you should lock the cache while the change is being performed?
- Dylan16807 6y agoI'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.