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

        Roman Puchkovskiy created issue -
        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.
        Roman Puchkovskiy made changes -
        Field Original Value New Value
        Attachment test-external-lock-in-tx.zip [ 12383122 ]
        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
        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); } }
        Claus Köll made changes -
        Assignee Claus Köll [ c_koell ]
        Hide
        Claus Köll added a comment -

        working patch ...

        Show
        Claus Köll added a comment - working patch ...
        Claus Köll made changes -
        Attachment patch2.txt [ 12407530 ]
        Claus Köll made changes -
        Component/s locks [ 11615 ]
        Component/s transactions [ 11616 ]
        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 -

        now it works

        Show
        Claus Köll added a comment - now it works
        Claus Köll made changes -
        Attachment patch2.txt [ 12407752 ]
        Claus Köll made changes -
        Attachment patch2.txt [ 12407530 ]
        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 -

        Resolved in revision 775868

        Show
        Claus Köll added a comment - Resolved in revision 775868
        Claus Köll made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.6.0 [ 12313459 ]
        Resolution Fixed [ 1 ]
        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?
        Jukka Zitting made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        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.
        Jukka Zitting made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Jukka Zitting made changes -
        Workflow jira [ 12432220 ] no-reopen-closed, patch-avail [ 12468083 ]
        Jukka Zitting made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        352d 17h 29m 1 Claus Köll 18/May/09 10:20
        Resolved Resolved Reopened Reopened
        2d 7h 18m 1 Jukka Zitting 20/May/09 17:39
        Reopened Reopened Resolved Resolved
        20m 54s 1 Jukka Zitting 20/May/09 17:59
        Resolved Resolved Closed Closed
        84d 22h 3m 1 Jukka Zitting 13/Aug/09 16:03

          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