Replies: 1 comment
-
In my opinion it should do your first suggestion of implicitly disabling cache since locking at the cache-level could lead to unexpected results (i.e. you could still perform updates on the 'locked' records since those could have been read pre-cache. This would then invalidate the cache and subsequent queries would bypass the cache lock etc.) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Describe the bug
It seems the
lockForUpdate()
method available for laravel queries does not work when caching has been enabled and there is a cache hit. I have not had time to look further into this but I was having problems with a query not locking when it should have, and I found adding->disableCache()
to the query instantly fixed the issue. I believe if the cache gets a hit it returns the record and ignores thelockForUpdate()
part of the query.I think the proper behaviour when
lockForUpdate()
is encountered is to possibly automatically disable cache or use cache key locking if the cache provider implementsIlluminate\Contracts\Cache\LockProvider
contract.Eloquent Query
An example of how to reproduce is below. In two different terminal sessions run artisan tinker, in one
session run the instance1 code, then in the other session while instance1 code is sleeping run instance2 code. When instance2 encounters the lock it should block until the lock is released, the issue I am seeing is that instance2 returns straight away rather than blocking.
Environment
Beta Was this translation helpful? Give feedback.
All reactions