[jira] Resolved: (JCR-1666) After transaction rollback session may become 'corrupt'

["Jukka Zitting (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCR-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved JCR-1666.
--------------------------------

      Assignee: Jukka Zitting
    Resolution: Duplicate

I believe this got fixed in JCR-2712.

> After transaction rollback session may become 'corrupt'
> -------------------------------------------------------
>
>                 Key: JCR-1666
>                 URL: https://issues.apache.org/jira/browse/JCR-1666
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, transactions, versioning
>    Affects Versions: core 1.4.5
>            Reporter: Roman Puchkovskiy
>            Assignee: Jukka Zitting
>
> Here's the test case. This method should be added to the org.apache.jackrabbit.core.XATest class.
>     public void testRollbackRefreshSave() throws Exception {
>         // get user transaction object
>         UserTransaction utx = new UserTransactionImpl(superuser);
>         // start transaction
>         utx.begin();
>         // add node and save
>         Node n = testRootNode.addNode("n");
>         n.addMixin(mixVersionable);
>         superuser.save();
>         // assertion: node exists in this session
>         String uuid = n.getUUID();
>         try {
>             superuser.getNodeByUUID(uuid);
>         } catch (ItemNotFoundException e) {
>             fail("New node not visible after save()");
>         }
>         // rollback
>         utx.rollback();
>         superuser.refresh(false);
>         // assertion: node does not exist in this session
>         try {
>             superuser.getNodeByUUID(uuid);
>             fail("Node still visible after rollback()");
>         } catch (ItemNotFoundException e) {
>             /* expected */
>         }
>         utx = new UserTransactionImpl(superuser);
>         utx.begin();
>         Node m = superuser.getRootNode().addNode("m");
>         m.addMixin(mixVersionable);
>         superuser.save();
>         utx.commit();
>     }
> This method creates a versionable node inside a tx, but the tx is rolled back. Then another versionable node is tried to be created through the same session, and this causes an exception to be thrown.
> Please note that if one of the nodes is not versionable this problem does not arise.
> As for the use case, it seems to be the sequence that happens when sessions are acquired through a connection pool. So when a rollback happens on some session, it becomes 'corrupt' because its next users get this exception when trying to create a versionable node.

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