[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1365) rollback *costly* removes the nodes created for locking

[ http://jira.jboss.com/jira/browse/JBCACHE-1365?page=all ] Mircea Markus updated JBCACHE-1365: ----------------------------------- Summary: rollback *costly* removes the nodes created for locking (was: rollback does not removes the nodes created for locking) Issue Type: Feature Request (was: Bug) Description: within a Tx: when adding a new k,v pair to an *inexistent* node, the supporting tree structure is created within the transaction. In order to be able to rollback the these structural nodes, a CreateNode command is created for each such operation - not optimal as for each such commands a List is also built internally. The drawback for Fqn.size = n is -> n commands and n lists being created, which is a lot. solution: nodes are being create in PessimisticLockInterceptor, they should be passed in to the command itself so that it will be aware of them at rollback time, i.e. don't create a new command just for creating a new node. was: within a Tx: when adding a new k,v pair to an *inexistent* node, the supporting tree structure is created within the transaction. This supporting (intermediate node to the final one) tree structure does not get deleteted on Rollback. e.g. public void testPutDataMap() throws Exception { HashMap map = new HashMap(); map.put("k","v"); assert !cache.exists("/a/b"); txMgr.begin(); cache.put("/a/b/c", map); assert cache.exists("/a/b"); txMgr.rollback(); assert !cache.exists("/a/b"); } solution: nodes are being create in PessimisticLockInterceptor, they should be passed in to the command itself so that it will be aware of them at rollback time, and it will remove them. Priority: Minor (was: Critical) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira