Uploaded image for project: 'OpenJPA'
  1. OpenJPA
  2. OPENJPA-2547

When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock.

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.2, 2.2.2, 2.2.1.1, 2.3.0, 2.4.0
    • Fix Version/s: 2.1.2, 2.2.2, 2.2.1.1, 2.4.0
    • Component/s: jdbc
    • Labels:
      None

      Description

      I have created a scenario where two threads both attempt to get a pessimistic lock on an object, where one thread legitimately gets the lock, and the other gets a 'false' lock. To describe this issue, lets look at a test. I will provide (attache) a full working test, but for now lets look at this snippet of the test which is at the heart of the issue:

      PessimisticLockEntity entity = oem.find(PessimisticLockEntity.class, pKey);

      boolean locked = false;
      while (!locked) {
      try

      { oem.getFetchPlan().setLockTimeout(5000); oem.lock(entity, LockModeType.PESSIMISTIC_READ); locked = true; }

      catch (PessimisticLockException ple) {

      With this test, imagine the case where two threads call this code at roughly the same time. In this case, one thread should receive a lock, and the other thread should receive a PessimisticLockException (PLE). In my test, this is what happens.....so far so good. However, the thread with the lock (call it T1) then sleeps for a while, and the thread which got the PLE (call it T2) attempts to get the lock over and over again. When T2 tries to get a lock while T1 holds the lock, T2 should continue to receive a PLE. However, I've found that T2 "gets" a lock. That is, a PLE is never thrown because OpenJPA doesn't execute SQL to obtain the lock. OpenJPA skips that steps and thinks T2 has a lock. This gives T2 a false lock.

      I've found that prior to JIRA OPENJPA-2449, we got the expected results (i.e. T2 continues to get a PLE while T1 holds the lock). It is only with OPENJPA-2449 that the incorrect behavior occurs.

      I will provide a patch which contains a potential fix, and a test that does two things: 1) tests the scenario above and 2) provides a test to verify OPENJPA-2449 (we never provided a test when we committed OPENJPA-2449). My fix, if correct, simply adds one additional check to the code added via OPENJPA-2449.

      Thanks,

      Heath

        Issue Links

          Activity

          Hide
          jpaheath Heath Thomann added a comment -

          I'm attaching a test for this issue, as well as a test for the related JIRA since a test was never provided for that JIRA. My patch also includes a proposed fix.

          Thanks,

          Heath

          Show
          jpaheath Heath Thomann added a comment - I'm attaching a test for this issue, as well as a test for the related JIRA since a test was never provided for that JIRA. My patch also includes a proposed fix. Thanks, Heath
          Hide
          curtisr7 Rick Curtis added a comment -

          Heath –

          You should use the LockLevels constant rather than a zero.

          ie:
          List<SQLBuffer> sqls = (sm.getLock() == null || sm.getLock().equals(org.apache.openjpa.kernel.LockLevels.LOCK_NONE ))

          Thanks,
          Rick

          Show
          curtisr7 Rick Curtis added a comment - Heath – You should use the LockLevels constant rather than a zero. ie: List<SQLBuffer> sqls = (sm.getLock() == null || sm.getLock().equals(org.apache.openjpa.kernel.LockLevels.LOCK_NONE )) Thanks, Rick
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1651808 from Heath Thomann in branch 'openjpa/branches/2.2.1.x'
          [ https://svn.apache.org/r1651808 ]

          OPENJPA-2547: When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to 2.2.1.x.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1651808 from Heath Thomann in branch 'openjpa/branches/2.2.1.x' [ https://svn.apache.org/r1651808 ] OPENJPA-2547 : When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to 2.2.1.x.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1651843 from Heath Thomann in branch 'openjpa/branches/2.1.x'
          [ https://svn.apache.org/r1651843 ]

          OPENJPA-2547: When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to 2.1.x.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1651843 from Heath Thomann in branch 'openjpa/branches/2.1.x' [ https://svn.apache.org/r1651843 ] OPENJPA-2547 : When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to 2.1.x.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1651846 from Heath Thomann in branch 'openjpa/branches/2.2.x'
          [ https://svn.apache.org/r1651846 ]

          OPENJPA-2547: When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to 2.2.x.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1651846 from Heath Thomann in branch 'openjpa/branches/2.2.x' [ https://svn.apache.org/r1651846 ] OPENJPA-2547 : When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to 2.2.x.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1651847 from Heath Thomann in branch 'openjpa/trunk'
          [ https://svn.apache.org/r1651847 ]

          OPENJPA-2547: When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to trunk.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1651847 from Heath Thomann in branch 'openjpa/trunk' [ https://svn.apache.org/r1651847 ] OPENJPA-2547 : When two threads attempt to get a Pessimistic Lock, one thread gets a 'false' lock. Applied fix to trunk.

            People

            • Assignee:
              Unassigned
              Reporter:
              jpaheath Heath Thomann
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development