Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2919

LockMode::NONE evaluation inconsistencies in ORM

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: DQL
    • Security Level: All
    • Labels:
      None
    • Environment:
      SQL Server, SQL Anywhere

      Description

      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.

        Issue Links

          Activity

          Hide
          Marco Pivetta added a comment -

          As discussed with Steve Müller on IRC, I think the original idea was to avoid putting any hint on queries without the user explicitly telling us to do so.

          Steve Müller 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.

          Show
          Marco Pivetta added a comment - As discussed with Steve Müller on IRC, I think the original idea was to avoid putting any hint on queries without the user explicitly telling us to do so. Steve Müller 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.
          Hide
          Benjamin Eberlei added a comment -

          Steve Müller Marco Pivetta does this need to ge tmerged into 2.4?

          Show
          Benjamin Eberlei added a comment - Steve Müller Marco Pivetta does this need to ge tmerged into 2.4?

            People

            • Assignee:
              Benjamin Eberlei
              Reporter:
              Steve Müller
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: