jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Prowse <c...@prowse.com>
Subject JCR-2701 Discussion
Date Fri, 22 Oct 2010 05:03:00 GMT

I've been looking into JCR-2701 (https://issues.apache.org/jira/browse/JCR-2701) which is
the error when attempting to clone nodes between workspaces when deployed on JCA.

Could someone with better knowledge of the inner working of Jackrabbit please verify and/or
clarify my understanding of how the internals are to work when creating a Workspace off of

I've followed through the logic and it seems to me that the root cause is that calling save
on a session does not persist to the underlying datastore due to it being part of a container
managed transaction.  However it seems the createWorkspace process has an incorrect assumption
on state, centred I believe around XAItemStateManager.

The reason I think this is a problem is threefold:
(1) - When calling save on a XASession that is part of a running transaction, it will not
persist to the underlying datastore and instead merge changes together for the final commit
(2). in WorkspaceImpl.createWorkspace(String,String), it uses the _CURRENT_ session to iterate
through all children of the root node, so that it can then issue a clone for each child node
name to the new workspace.
(3). in WorkspaceImpl.clone() it creates a _NEW_ session on the source workspace to copy nodes

Since (1) means the changes are not available to other sessions, (2) sees the "saved" nodes,
but (3) does not and so fails with the PathNotFoundException.

So a workaround for the problem is to use bean managed transactions which commit the user
transaction after the save, and before the creation of a new workspace, which I have verified

However to me it seems the assumption in WorkspaceImpl.clone could cause other problems where
an overlying transaction is in place, causing it to attempt to copy unpersisted (but saved!)

Would love to hear someone else's thoughts on that.  I can update the JIRA issue with the
above info if it is verified by someone else.

 -- Cory
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message