jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@day.com>
Subject Re: JCR-2701 Discussion
Date Fri, 22 Oct 2010 14:04:02 GMT
hi cory,

On Fri, Oct 22, 2010 at 7:03 AM, Cory Prowse <cory@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,

> 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

View raw message