Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-1634

In XA transaction session.addLockToken() does not have effect

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: core 1.4.4
    • Fix Version/s: 1.6
    • Component/s: jackrabbit-core
    • Labels:
      None
    • Environment:
      Jackrabbit Core 1.4.4, Jencks 2.0, Springmodules 0.8a, Jackrabbit JCA 1.4

      Description

      Following sequence does not work as expected:
      1. first tx (and first session)
      create node
      make it lockable
      2. second tx (and second session)
      lock this node and save lock token
      3. third tx (and third session)
      add saved lock token to session
      modify this locked node -> fails as if lock token was not added to session3

      The same sequence works as expected without transactions.
      I had to separate transactions 1 and 2 because JCR-1633 prevents node from being locked in same tx in which it was created.

      1. test-external-lock-in-tx.zip
        6 kB
        Roman Puchkovskiy
      2. patch2.txt
        10 kB
        Claus Köll

        Activity

        Hide
        Jukka Zitting added a comment -

        Sorry for the noise. The test (and merge) failure was caused by the fact that I hadn't yet merged the JCR-1633 fix to the 1.x branch. After merging JCR-1633, this fix merged cleanly and passed all tests.

        Merged to the 1.x branch in revision 776766.

        Show
        Jukka Zitting added a comment - Sorry for the noise. The test (and merge) failure was caused by the fact that I hadn't yet merged the JCR-1633 fix to the 1.x branch. After merging JCR-1633 , this fix merged cleanly and passed all tests. Merged to the 1.x branch in revision 776766.
        Hide
        Jukka Zitting added a comment -

        I tried merging this to the 1.x branch (svn merge -c 775868 https://svn.apache.org/repos/asf/jackrabbit/trunk), but I'm getting the following test failure there (after fixing the trivial XATest merge failure):

        testAddRemoveLockToken(org.apache.jackrabbit.core.XATest) Time elapsed: 0.005 sec <<< ERROR!
        javax.transaction.RollbackException: Transaction rolled back: XA_ERR=104
        at org.apache.jackrabbit.core.UserTransactionImpl.commit(UserTransactionImpl.java:159)
        at org.apache.jackrabbit.core.XATest.testAddRemoveLockToken(XATest.java:1000)
        Caused by: org.apache.jackrabbit.core.TransactionException: Unable to update.
        at org.apache.jackrabbit.core.lock.XAEnvironment.prepare(XAEnvironment.java:345)
        at org.apache.jackrabbit.core.lock.XALockManager.prepare(XALockManager.java:254)
        at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
        at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:331)
        at org.apache.jackrabbit.core.UserTransactionImpl.commit(UserTransactionImpl.java:121)
        ... 30 more
        Caused by: javax.jcr.ItemNotFoundException: failed to build path of f3a5bece-ced2-4baf-909c-e13e9685893c: f3a5bece-ced2-4baf-909c-e13e9685893c: f3a5bece-ced2-4baf-909c-e13e9685893c
        at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:398)
        at org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:229)
        at org.apache.jackrabbit.core.lock.LockManagerImpl.getPath(LockManagerImpl.java:702)
        at org.apache.jackrabbit.core.lock.LockManagerImpl.internalLock(LockManagerImpl.java:318)
        at org.apache.jackrabbit.core.lock.XAEnvironment$LockInfo.update(XAEnvironment.java:492)
        at org.apache.jackrabbit.core.lock.XAEnvironment.prepare(XAEnvironment.java:343)
        ... 34 more
        Caused by: org.apache.jackrabbit.core.state.NoSuchItemStateException: f3a5bece-ced2-4baf-909c-e13e9685893c
        at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:185)
        at org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(HierarchyManagerImpl.java:150)
        at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:393)
        ... 39 more

        Claus, do you want to give this a look in the 1.x branch or should we simply declare this as fixed for just the 2.0 release?

        Show
        Jukka Zitting added a comment - I tried merging this to the 1.x branch (svn merge -c 775868 https://svn.apache.org/repos/asf/jackrabbit/trunk ), but I'm getting the following test failure there (after fixing the trivial XATest merge failure): testAddRemoveLockToken(org.apache.jackrabbit.core.XATest) Time elapsed: 0.005 sec <<< ERROR! javax.transaction.RollbackException: Transaction rolled back: XA_ERR=104 at org.apache.jackrabbit.core.UserTransactionImpl.commit(UserTransactionImpl.java:159) at org.apache.jackrabbit.core.XATest.testAddRemoveLockToken(XATest.java:1000) Caused by: org.apache.jackrabbit.core.TransactionException: Unable to update. at org.apache.jackrabbit.core.lock.XAEnvironment.prepare(XAEnvironment.java:345) at org.apache.jackrabbit.core.lock.XALockManager.prepare(XALockManager.java:254) at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154) at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:331) at org.apache.jackrabbit.core.UserTransactionImpl.commit(UserTransactionImpl.java:121) ... 30 more Caused by: javax.jcr.ItemNotFoundException: failed to build path of f3a5bece-ced2-4baf-909c-e13e9685893c: f3a5bece-ced2-4baf-909c-e13e9685893c: f3a5bece-ced2-4baf-909c-e13e9685893c at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:398) at org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:229) at org.apache.jackrabbit.core.lock.LockManagerImpl.getPath(LockManagerImpl.java:702) at org.apache.jackrabbit.core.lock.LockManagerImpl.internalLock(LockManagerImpl.java:318) at org.apache.jackrabbit.core.lock.XAEnvironment$LockInfo.update(XAEnvironment.java:492) at org.apache.jackrabbit.core.lock.XAEnvironment.prepare(XAEnvironment.java:343) ... 34 more Caused by: org.apache.jackrabbit.core.state.NoSuchItemStateException: f3a5bece-ced2-4baf-909c-e13e9685893c at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:185) at org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(HierarchyManagerImpl.java:150) at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:393) ... 39 more Claus, do you want to give this a look in the 1.x branch or should we simply declare this as fixed for just the 2.0 release?
        Hide
        Claus Köll added a comment -

        Resolved in revision 775868

        Show
        Claus Köll added a comment - Resolved in revision 775868
        Hide
        Marius Ropotica added a comment -

        Great. I didn't test the patch, but as soon as I will test it, I will provide feedback. Is there any planned release that include this patch?

        Show
        Marius Ropotica added a comment - Great. I didn't test the patch, but as soon as I will test it, I will provide feedback. Is there any planned release that include this patch?
        Hide
        Claus Köll added a comment -

        now it works

        Show
        Claus Köll added a comment - now it works
        Hide
        Claus Köll added a comment -

        arg ... works not perfect ... i will investigate mor time

        Show
        Claus Köll added a comment - arg ... works not perfect ... i will investigate mor time
        Hide
        Claus Köll added a comment -

        working patch ...

        Show
        Claus Köll added a comment - working patch ...
        Hide
        Marius Ropotica added a comment -

        Well, I've modified the XAEnvironment and XALockManager classes. I'm not sure that this is the right solution, but it seems that the problem is gone.

        In XAEnvironment I've modified addLockToken and removeLockToken methods as following:

        public void addLockToken(SessionImpl session, String lt)

        { lockMgr.lockTokenAdded(session, lt); }

        public void removeLockToken(SessionImpl session, String lt)

        { lockMgr.lockTokenRemoved(session, lt); }

        and in XALockManager class the following methods:

        public void lockTokenAdded(SessionImpl session, String lt) {
        if (isInXA())

        { xaEnv.addLockToken(session, lt); }

        else

        { lockMgr.lockTokenAdded(session, lt); }

        }

        public void lockTokenRemoved(SessionImpl session, String lt) {
        if (isInXA())

        { xaEnv.removeLockToken(session, lt); }

        else

        { lockMgr.lockTokenRemoved(session, lt); }

        }

        Show
        Marius Ropotica added a comment - Well, I've modified the XAEnvironment and XALockManager classes. I'm not sure that this is the right solution, but it seems that the problem is gone. In XAEnvironment I've modified addLockToken and removeLockToken methods as following: public void addLockToken(SessionImpl session, String lt) { lockMgr.lockTokenAdded(session, lt); } public void removeLockToken(SessionImpl session, String lt) { lockMgr.lockTokenRemoved(session, lt); } and in XALockManager class the following methods: public void lockTokenAdded(SessionImpl session, String lt) { if (isInXA()) { xaEnv.addLockToken(session, lt); } else { lockMgr.lockTokenAdded(session, lt); } } public void lockTokenRemoved(SessionImpl session, String lt) { if (isInXA()) { xaEnv.removeLockToken(session, lt); } else { lockMgr.lockTokenRemoved(session, lt); } }
        Hide
        Marius Ropotica added a comment - - edited

        I'm using jackrabbit 1.5 now , and this bug is not yet resolved. What is happening? Why this bug is ignored? Did anyone found workarounds for this problem?

        This is the code that I'm trying to run in a transaction:

        session.addLockToken(token);
        Node node = session.getNodeByUUID(id);
        node.unlock();

        addLockToken method from SessionImpl delegates to method addLockToken from XAEnvironment class. This method is empty.

        Show
        Marius Ropotica added a comment - - edited I'm using jackrabbit 1.5 now , and this bug is not yet resolved. What is happening? Why this bug is ignored? Did anyone found workarounds for this problem? This is the code that I'm trying to run in a transaction: session.addLockToken(token); Node node = session.getNodeByUUID(id); node.unlock(); addLockToken method from SessionImpl delegates to method addLockToken from XAEnvironment class. This method is empty.
        Hide
        Roman Puchkovskiy added a comment -

        Attaching test case. It contains two test methods: one without transactions, another using transactions.

        Show
        Roman Puchkovskiy added a comment - Attaching test case. It contains two test methods: one without transactions, another using transactions.

          People

          • Assignee:
            Claus Köll
            Reporter:
            Roman Puchkovskiy
          • Votes:
            10 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development