Question

We currently have a read-through cache that uses optimistic concurrency control when filling the cache on cache misses. We don’t anticipate many conflicts, so we chose to use optimistic concurrency control. I’m a bit unsure what to do when we actually have a conflict though.

If we have a cache miss, we pull the relevant row from the database, and then put it into the cache for future reference. Before we put it in the cache, we ensure that the value of the cache key has not changed since our initial database read. If it has, I’m currently leaning towards invalidating the cache entry, just to be on the safe side, but this seems a bit inefficient. Are there any better alternatives, that are still safe?

For the record, we are using Redis for our cache-layer and MySQL for our backing-store.

Answer 1

If conflicts are few-and-far-between then why not just WATCH the key again, generate the cache data again, and try populating Redis again. Just keep repeating this process until your EXEC finally comes back clean. You could set a max number of retries to something sane, and if that is ever exceeded just invalidate the cache and notify your admins. The notification step seems important because if your optimistic lock fails more than something like 5 times then there is probably something weird going on and you should take a closer look.