Should locking a result for PESSIMISTIC_WRITE refresh the entity cache?

[shauno]

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

[Ocramius]

@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]

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.