Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <734905508.1216400671776.JavaMail.jira@brutus>
Date: Fri, 18 Jul 2008 10:04:31 -0700 (PDT)
From: =?utf-8?Q?R=C3=BCdiger_Gro=C3=9F-Hardt_=28JIRA=29?= <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1685) Version node still accessible after
 transaction rollback
In-Reply-To: <1779708072.1216396951780.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-1685?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D126147=
89#action_12614789 ]=20

R=C3=BCdiger Gro=C3=9F-Hardt commented on JCR-1685:
-----------------------------------------

>> Thanks for the test case, the problem is already known. Changing it requ=
ires a lot of changes to the code.=20

I do not quite agree, because to me the rollback on the versioning db conne=
ction seems to fail all the time, while the other issue is really categoriz=
ed as an improvement and merely mentions a possible problem. Which is BTW, =
why I felt this was a new issue.=20

>> Do you currently have any real issues with it? (A version node in the ve=
rsioning subtree that is not referenced by any node in the workspace is not=
 nice, but not a big issue IMHO).

As the code indicates, I have found a workaround, so no, we do not have a r=
eal issue with it so far.

> Version node still accessible after transaction rollback
> --------------------------------------------------------
>
>                 Key: JCR-1685
>                 URL: https://issues.apache.org/jira/browse/JCR-1685
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core, transactions, versioning
>    Affects Versions: core 1.4.5
>         Environment: Windows Vista, Java 1.5.0, Derby Database for versio=
ning and workspace, JUnit 4 Testcase
>            Reporter: R=C3=BCdiger Gro=C3=9F-Hardt
>         Attachments: TransactionTest.java, UserTransactionImpl.java
>
>
> * Open a transaction
> * Add a new versionable node and check it in
> * Save the uuid of the version node returned by node.checkin()
> * Rollback transaction AND call session.refresh(false)
> * access version (!) node by session.getNodeByUUID()
> =3D=3D> in spite of the rollback the version node is still found. If the =
path of the version node is used to look it up (session.getItem()), it fail=
s
> The following JUnit 4 test case demonstrates the problem:
>     @Test
>     public void testRollbackInline() throws Exception {
>         // start transaction for session
>         UserTransactionImpl tx =3D new UserTransactionImpl(superuser);
>         tx.begin();
>         // add new node and save
>         Node node =3D superuser.getRootNode().addNode("test001", "nt:unst=
ructured");
>         node.addMixin("mix:versionable");
>         superuser.save();
>         // checkin version and save uuid
>         Version v =3D node.checkin();
>         String uuid =3D v.getUUID();
>         // rollback transaction for session
>         tx.rollback();
>         // clear transient storage
>         superuser.refresh(false);
>         // check, whether new version was really "rolled back"
>         assertFalse(hasVersionWorks(uuid));
>         assertFalse(hasVersionFails(uuid));
>     }
>     private boolean hasVersionFails(String versionId) throws RepositoryEx=
ception {
>         boolean hasVersion;
>         try {
>             Node nodeByUUID =3D superuser.getNodeByUUID(versionId);
>             hasVersion =3D nodeByUUID !=3D null;
>         } catch (ItemNotFoundException e) {
>             hasVersion =3D false;
>         }
>         if (hasVersion)
>             System.err.println("hasVersionFailing: " + versionId + " =3D=
=3D> FOUND");
>         else
>             System.err.println("hasVersionFailing: " + versionId + " =3D=
=3D> NOT FOUND");
>         return hasVersion;
>     }
>     private boolean hasVersionWorks(String versionId) throws RepositoryEx=
ception {
>         boolean hasVersion;
>         try {
>             Node nodeByUUID =3D superuser.getNodeByUUID(versionId);
>             String path =3D nodeByUUID.getPath();
>             hasVersion =3D superuser.itemExists(path);
>         } catch (ItemNotFoundException e) {
>             hasVersion =3D false;
>         }
>         if (hasVersion)
>             System.err.println("hasVersionWorking: " + versionId + " =3D=
=3D> FOUND");
>         else
>             System.err.println("hasVersionWorking: " + versionId + " =3D=
=3D> NOT FOUND");
>         return hasVersion;
>     }
> I will try to attach the complete test sources, which also shows the setu=
p of the repository, though I did nothing special there.

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