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

[Roman Puchkovskiy (JIRA)]

After transaction rollback session may become 'corrupt'
-------------------------------------------------------

                 Key: JCR-1666
                 URL: https://issues.apache.org/jira/browse/JCR-1666
             Project: Jackrabbit
          Issue Type: Bug
          Components: jackrabbit-core, transactions, versioning
    Affects Versions: core 1.4.5
            Reporter: Roman Puchkovskiy


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.