Should locking a result for PESSIMISTIC_WRITE refresh the entity cache? #5658

New Issue

admin · 2026-01-22T15:13:56+01:00

admin commented

2026-01-22 15:13:56 +01:00

Originally created by @shauno on GitHub (Aug 26, 2017).

Originally assigned to: @lcobucci on GitHub.

I'm new to Doctrine and recently ran into an issue in a high(ish) concurrency environment.

In short, when fetching an entity with $query->setLockMode(LockMode::PESSIMISTIC_WRITE);, the result will be overwritten with a cached result if that entity has been fetched earlier in the script (even though the actual query will correctly wait on getting a proper lock, and return the latest correct data).

In researching the issue, I found I can add a ->setHint(Query::HINT_REFRESH, true) to the query which will make sure the entity is not loaded from cache, but should that not be the default behavior when using a LockMode::PESSIMISTIC_WRITE on the query?

I've put together a simple repo illustrating the issue here: https://github.com/shauno/doctrine-stale-demo

Originally created by @shauno on GitHub (Aug 26, 2017). Originally assigned to: @lcobucci on GitHub. I'm new to Doctrine and recently ran into an issue in a high(ish) concurrency environment. In short, when fetching an entity with `$query->setLockMode(LockMode::PESSIMISTIC_WRITE);`, the result will be overwritten with a cached result if that entity has been fetched earlier in the script (even though the actual query will correctly wait on getting a proper lock, and return the latest correct data). In researching the issue, I found I can add a `->setHint(Query::HINT_REFRESH, true)` to the query which will make sure the entity is not loaded from cache, but should that not be the default behavior when using a `LockMode::PESSIMISTIC_WRITE` on the query? I've put together a simple repo illustrating the issue here: https://github.com/shauno/doctrine-stale-demo

admin added the Bug Missing Tests Question labels 2026-01-22 15:13:56 +01:00

admin commented

2026-01-22 15:13:56 +01:00

@Ocramius commented on GitHub (Aug 28, 2017):

@shauno I'd say that a pessimistic write should not use the L2 cache at all. @lcobucci thoughts?

I've put together a simple repo illustrating the issue here: https://github.com/shauno/doctrine-stale-demo

We can't do much with demos if they aren't in our test suite, sorry :-(

@Ocramius commented on GitHub (Aug 28, 2017): @shauno I'd say that a pessimistic write should not use the L2 cache at all. @lcobucci thoughts? > I've put together a simple repo illustrating the issue here: https://github.com/shauno/doctrine-stale-demo We can't do much with demos if they aren't in our test suite, sorry :-(

admin commented

2026-01-22 15:13:57 +01:00

@Ocramius commented on GitHub (Aug 28, 2017):

Ah yes, in order to ensure that other clients are blocked, then a pessimistic write lock is also required to clear the cache. I'd say this only applies to a READ_WRITE cache, not to other caching mechanisms. If another client wants to read the data without actually modifying it, NONSTRICT_READ_WRITE should just keep going, without being affected by the lock.

The "why" of this needs to be pictured in a series of test scenarios.

@Ocramius commented on GitHub (Aug 28, 2017): Ah yes, in order to ensure that other clients are blocked, then a pessimistic write lock is also required to clear the cache. I'd say this only applies to a `READ_WRITE` cache, not to other caching mechanisms. If another client wants to read the data without actually modifying it, `NONSTRICT_READ_WRITE` should just keep going, without being affected by the lock. The "why" of this needs to be pictured in a series of test scenarios.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5658