jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rüdiger Groß-Hardt (JIRA) <j...@apache.org>
Subject [jira] Commented: (JCR-1685) Version node still accessible after transaction rollback
Date Fri, 18 Jul 2008 17:04:31 GMT

    [ https://issues.apache.org/jira/browse/JCR-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614789#action_12614789
] 

Rüdiger Groß-Hardt commented on JCR-1685:
-----------------------------------------

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

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

>> Do you currently have any real issues with it? (A version node in the versioning
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 real 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 versioning and workspace,
JUnit 4 Testcase
>            Reporter: Rüdiger Groß-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()
> ==> 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 fails
> The following JUnit 4 test case demonstrates the problem:
>     @Test
>     public void testRollbackInline() throws Exception {
>         // start transaction for session
>         UserTransactionImpl tx = new UserTransactionImpl(superuser);
>         tx.begin();
>         // add new node and save
>         Node node = superuser.getRootNode().addNode("test001", "nt:unstructured");
>         node.addMixin("mix:versionable");
>         superuser.save();
>         // checkin version and save uuid
>         Version v = node.checkin();
>         String uuid = 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 RepositoryException {
>         boolean hasVersion;
>         try {
>             Node nodeByUUID = superuser.getNodeByUUID(versionId);
>             hasVersion = nodeByUUID != null;
>         } catch (ItemNotFoundException e) {
>             hasVersion = false;
>         }
>         if (hasVersion)
>             System.err.println("hasVersionFailing: " + versionId + " ==> FOUND");
>         else
>             System.err.println("hasVersionFailing: " + versionId + " ==> NOT FOUND");
>         return hasVersion;
>     }
>     private boolean hasVersionWorks(String versionId) throws RepositoryException {
>         boolean hasVersion;
>         try {
>             Node nodeByUUID = superuser.getNodeByUUID(versionId);
>             String path = nodeByUUID.getPath();
>             hasVersion = superuser.itemExists(path);
>         } catch (ItemNotFoundException e) {
>             hasVersion = false;
>         }
>         if (hasVersion)
>             System.err.println("hasVersionWorking: " + versionId + " ==> FOUND");
>         else
>             System.err.println("hasVersionWorking: " + versionId + " ==> NOT FOUND");
>         return hasVersion;
>     }
> I will try to attach the complete test sources, which also shows the setup of the repository,
though I did nothing special there.

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


Mime
View raw message