[Question] Optimistic Locking behaviour for dirty entities #5842

New Issue

admin · 2026-01-22T15:19:42+01:00

admin commented

2026-01-22 15:19:42 +01:00

Originally created by @tavlima on GitHub (Jan 11, 2018).

I was surprised to see that Doctrine\ORM\EntityManager::find is able to find an entity matching the lockVersion constraint, even when the changes were not persisted yet.

$user_v1 = $em->find(User:class, 1, LockMode::OPTIMISTIC, 1);
$user_v1->setVersion(2);

// I'd expect this next line to throw an OptimisticLockException, given there were no flushes in the between...
$user_v2 = $em->find(User:class, 1, LockMode::OPTIMISTIC, 2);

I get that the find is optimised to check the identity map first, before hitting the database, but is there a reason do that even when explicitly locking?

Couldn't we check if the identity mapped entity is not dirty and, only in that case, return from there and correctly short-circuit the DB query? I really think the current behaviour can be misleading in some scenarios...

Originally created by @tavlima on GitHub (Jan 11, 2018). I was surprised to see that `Doctrine\ORM\EntityManager::find` is able to find an entity matching the `lockVersion` constraint, even when the changes were not persisted yet. ``` $user_v1 = $em->find(User:class, 1, LockMode::OPTIMISTIC, 1); $user_v1->setVersion(2); // I'd expect this next line to throw an OptimisticLockException, given there were no flushes in the between... $user_v2 = $em->find(User:class, 1, LockMode::OPTIMISTIC, 2); ``` I get that the `find` is optimised to check the identity map first, before hitting the database, but is there a reason do that even when explicitly locking? Couldn't we check if the identity mapped entity is not dirty and, only in that case, return from there and correctly short-circuit the DB query? I really think the current behaviour can be misleading in some scenarios...

admin closed this issue

2026-01-22 15:19:43 +01:00

admin commented

2026-01-22 15:19:43 +01:00

@beberlei commented on GitHub (Dec 7, 2020):

But the entity manager is responsible for the entity and it has it in version 2. I think this behavior is correct.

@beberlei commented on GitHub (Dec 7, 2020): But the entity manager is responsible for the entity and it has it in version 2. I think this behavior is correct.

admin referenced this issue

2026-01-22 16:05:18 +01:00

[PR #5842] Fixing setResultCacheProfile when handling null profile #9752

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#5842