JCR-2701 Discussion

[Cory Prowse <co...@prowse.com>]

Hi,

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 another.

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 from.

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 works.

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!) nodes.

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

Re: JCR-2701 Discussion

[Stefan Guggisberg <st...@day.com>]

hi cory,

On Fri, Oct 22, 2010 at 7:03 AM, Cory Prowse <co...@prowse.com> wrote:
> Hi,
>
> 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 another.
>
> 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 from.
>
> 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.

yes, you're right.

>
> 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 works.
>
> 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!) nodes.

agreed. unfortunately i am not familiar with jackrabbit's JTA support.
maybe somebody more knowledgeable can help here.
of course, if you can provide a patch, that would be very appreciated :).

thanks for your excellent analysis,
cheers
stefan

>
> 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