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 READUNCOMMITTED whereas in SQL Server for example the default transaction isolation level is READCOMMITTED.
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.
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 ( doctrine/dbal#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.
Issue was closed with resolution "Fixed"
Comment created by @beberlei:
[deeky666] [ocramius] does this need to ge tmerged into 2.4?