You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tomasz Kleszczynski (JIRA)" <ji...@apache.org> on 2014/09/10 07:43:29 UTC

[jira] [Updated] (JCR-3808) Workspace.clone() fails after VersionManager.checkin() when two sessions are within the same XA Transaction

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

Tomasz Kleszczynski updated JCR-3808:
-------------------------------------
    Summary: Workspace.clone() fails after VersionManager.checkin() when two sessions are within the same XA Transaction  (was: Workspace.clone() fails after VersionManager.checkin() when XA Transactions is used)

> Workspace.clone() fails after VersionManager.checkin() when two sessions are within the same XA Transaction
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JCR-3808
>                 URL: https://issues.apache.org/jira/browse/JCR-3808
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.9
>            Reporter: Tomasz Kleszczynski
>         Attachments: CheckinCloneTest.java
>
>
> There is following case:
> workspace 'default' contains versionable node '/repo/a/b'
> session1 uses workspace 'default'
> session2 uses workspace 'workspace2'
> both sessions are enlisted within the same XA Transaction
> Following transactional operation fails at point 2:
> 1. Create version of node '/repo/a/b' using session1.
> 2. Clone node '/repo/a/b' from workspace 'default' to 'workspace2'.
> 3. Remove node '/repo/a/b' from workspace 'workspace2'.
> Within Workspace.clone(), BatchedItemOperations.copyNodeState (case CLONE) checks if NodeId being copied already exists within destination workspace. Unfortunately this returns true when transaction is used. XAItemStateManager finds this item state in 'tx log'. As a consequence ItemExistsException is thrown.
> When in the same environment, Workspace.clone() is invoked with parameter removeExisting = true, javax.jcr.ItemNotFoundException is thrown by BatchedItemOperations.checkRemoveNode. 
> So both clone operations fails with opposite exceptions, in first case (removeExisting=false) - item exists, in second one (removeExisting=true) - item doesn't exist
> How both sessions are separated? Should 'tx log' be shared?
> Spec (21.3 Save vs. Commit) says that changes are visible to other sessions upon commit. But what if both sessions are within the same transaction?
> See attached unit test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)