jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (JCR-1634) In XA transaction session.addLockToken() does not have effect
Date Wed, 20 May 2009 16:40:45 GMT

     [ https://issues.apache.org/jira/browse/JCR-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jukka Zitting reopened JCR-1634:
--------------------------------


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?

> In XA transaction session.addLockToken() does not have effect
> -------------------------------------------------------------
>
>                 Key: JCR-1634
>                 URL: https://issues.apache.org/jira/browse/JCR-1634
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: core 1.4.4
>         Environment: Jackrabbit Core 1.4.4, Jencks 2.0, Springmodules 0.8a, Jackrabbit
JCA 1.4
>            Reporter: Roman Puchkovskiy
>            Assignee: Claus Köll
>             Fix For: 1.6.0
>
>         Attachments: patch2.txt, test-external-lock-in-tx.zip
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message