You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 29, 2020. It is now read-only.
And with APCu 5.1, this can be override to use new "apcu_entry" API which will manage a lock to avoid bad run race condition, and a single execution of the callback.
The text was updated successfully, but these errors were encountered:
When control enters apcu_entry() the lock for the cache is acquired exclusively, it is released when control leaves apcu_entry()
Does that mean the lock for the exact same entry/key or are there other entries/keys effected, too?
"exclusively" means other processes reading and writing the same key are waiting for the callback to finish.
Are other writes waiting for the lock to finish and afterwards overwrite the entry? Or are concurrent writes directly blocked (return false)? Does that makes sense?
-> This could happen if you have different logic writing the same entry like cache warm-up.
The only APCu function that can be called safely by generator is apcu_entry().
For me it means that the result of the callback will be automatically written to cache so your implementation would not be correct as it doesn't store the result. Or should the generator function take care or writing the valid result into cache? This would be more flexible because of some generator function doesn't throw exceptions or also could generate more than one entries.
Implementation could looks like
And with APCu 5.1, this can be override to use new "apcu_entry" API which will manage a lock to avoid bad run race condition, and a single execution of the callback.
The text was updated successfully, but these errors were encountered: