DDC-2919: LockMode::NONE evaluation inconsistencies in ORM #3634

New Issue

admin · 2026-01-22T14:24:18+01:00

admin commented

2026-01-22 14:24:18 +01:00

Originally created by @doctrinebot on GitHub (Jan 15, 2014).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user @deeky666:

ORM has inconsistencies in evaluating LockMode::NONE throughout the classes. Using LockMode::NONE is different from using no LockMode at all because on platforms that use table lock hints, there exists an explicit hint for not locking tables at all for a specific query.
ORM's method signatures use a default value of LockMode::NONE where applicable which causes the platforms to append a "NOLOCK" table hint to the query instead of not appending any table lock hint at all.
This is a problem because a "NOLOCK" table hint changes the transaction isolation level to READ_UNCOMMITTED whereas in SQL Server for example the default transaction isolation level is READ_COMMITTED.
ORM should use "null" or "false" as default value for lock modes so that by default no table lock hint is appended to the query and the user explicitly has to specify LockMode::NONE if he desires it.

This only affects SQL Server in ORM < 2.5 and will also affect SQL Anywhere in ORM >= 2.5.

Originally created by @doctrinebot on GitHub (Jan 15, 2014). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user @deeky666: ORM has inconsistencies in evaluating LockMode::NONE throughout the classes. Using LockMode::NONE is different from using no LockMode at all because on platforms that use table lock hints, there exists an explicit hint for not locking tables at all for a specific query. ORM's method signatures use a default value of LockMode::NONE where applicable which causes the platforms to append a "NOLOCK" table hint to the query instead of not appending any table lock hint at all. This is a problem because a "NOLOCK" table hint changes the transaction isolation level to READ_UNCOMMITTED whereas in SQL Server for example the default transaction isolation level is READ_COMMITTED. ORM should use "null" or "false" as default value for lock modes so that by default no table lock hint is appended to the query and the user explicitly has to specify LockMode::NONE if he desires it. This only affects SQL Server in ORM < 2.5 and will also affect SQL Anywhere in ORM >= 2.5.

admin added the Bug label 2026-01-22 14:24:18 +01:00

admin closed this issue

2026-01-22 14:24:18 +01:00

admin commented

2026-01-22 14:24:19 +01:00

@doctrinebot commented on GitHub (Jan 15, 2014):

@doctrinebot commented on GitHub (Jan 15, 2014): - relates to [DDC-2310: Recent changes to DBAL SQL Server platform lock hinting breaks ORM SqlWalker in DQL queries with joins](http://www.doctrine-project.org/jira/browse/DDC-2310) - relates to [DDC-2675: WITH (NOLOCK) failing when using JOIN](http://www.doctrine-project.org/jira/browse/DDC-2675)

admin commented

2026-01-22 14:24:19 +01:00

@doctrinebot commented on GitHub (Jan 15, 2014):

Comment created by @ocramius:

As discussed with [_{deeky] on IRC, I think the original idea was to avoid putting any hint on queries without the user explicitly telling us to do so.}

[deeky] has redesigned AbstractPlatform::appendLockHint() to actually differentiate between null and integer being passed in in DBAL-783 ( https://github.com/doctrine/dbal/pull/508 ), and we have some LockMode::NONE going through even when null was intended.

The idea was to introduce a minor BC break here and pass in null everywhere, and change the default param values to null. That needs documentation since it may affect some larger transactional systems.

@doctrinebot commented on GitHub (Jan 15, 2014): Comment created by @ocramius: As discussed with [<sub>deeky] on IRC, I think the original idea was to avoid putting any hint on queries without the user explicitly telling us to do so. [</sub>deeky] has redesigned `AbstractPlatform::appendLockHint()` to actually differentiate between `null` and `integer` being passed in in [DBAL-783](http://www.doctrine-project.org/jira/browse/DBAL-783) ( https://github.com/doctrine/dbal/pull/508 ), and we have some `LockMode::NONE` going through even when `null` was intended. The idea was to introduce a minor BC break here and pass in `null` everywhere, and change the default param values to `null`. That needs documentation since it may affect some larger transactional systems.

admin commented

2026-01-22 14:24:20 +01:00

@doctrinebot commented on GitHub (Feb 8, 2014):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Feb 8, 2014): Issue was closed with resolution "Fixed"

admin commented

2026-01-22 14:24:20 +01:00

@doctrinebot commented on GitHub (Feb 8, 2014):

Comment created by @beberlei:

[_{deeky666] [}ocramius] does this need to ge tmerged into 2.4?

@doctrinebot commented on GitHub (Feb 8, 2014): Comment created by @beberlei: [<sub>deeky666] [</sub>ocramius] does this need to ge tmerged into 2.4?

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