[JCR-1666] After transaction rollback session may become 'corrupt'

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: core 1.4.5
• Component/s: jackrabbit-core, transactions, versioning
• Assignee: Jukka Zitting
• Reporter: Roman Puchkovskiy
• Created: 30/Jun/08 16:18
• Updated: 27/Sep/11 21:39
• Resolved: 24/Sep/10 10:38

Description

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.