[ydah]

Concurrent unless_exist writes to a missing key can all succeed, and concurrent increments can lose updates because SELECT ... FOR UPDATE has no row to lock.

Insert a placeholder before locking and reading the entry. Keep it within the transaction, replace it on write, and remove it when the block returns no value. A zero byte size distinguishes placeholders from valid empty values.

[tkawa]

This looks like it addresses the same problem as #297: lock_and_write can't serialize access to a missing key, because there is no row for SELECT ... FOR UPDATE to lock. Both PRs take the same approach of inserting a placeholder row before locking and removing it when nothing is written.

The main differences:

• Placeholder: Fix lock_and_write races for missing cache entries #297 uses a serialized, already-expired ActiveSupport::Cache::Entry, so it goes through the normal deserialize/expiry path. This PR uses an empty value with byte_size: 0 as a sentinel, which keeps the change contained in Entry.
• Scope: Fix lock_and_write races for missing cache entries #297 enables the placeholder through a placeholder_payload: argument passed down from the store (three files). This PR always inserts it in Entry.lock_and_write.
• SQLite: Fix lock_and_write races for missing cache entries #297 retries database is locked in library code when inserting the placeholder. This PR handles it only in the test helper.

I'm fine with either approach being merged. If this one is preferred, I'll close #297.