[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-611) Optimize modification list before replication

Optimize modification list before replication --------------------------------------------- Key: JBCACHE-611 URL: https://jira.jboss.org/jira/browse/JBCACHE-611 Project: JBoss Cache Issue Type: Feature Request Security Level: Public(Everyone can see) Components: Replication Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.GA, 1.3.0.SP1 Reporter: Bela Ban Assignee: Mircea Markus Fix For: 3.0.0.GA When we use transactions, all modifications (PUT,REMOVE) are bundled (keyed by TX-ID) and replicated on TX commit. This is very inefficient if (a) we have many modifications in the TX scope and (b) if the modifications touched the same parts of the cache over and over again. We need to optimize the modification list before replication. (This maybe enabled/disabled via an attribute). Example: put(a/b/c) --> put(/a/b/c/d) --> remove(/a/b/c) --> put(a/b/c) should simply result in a PUT modification with *all* of the attributes of /a/b/c, so 1 modification instead of 4 ! A general algorithm might be: - Maintain a dirty-node map Map<FQN, status>) (= "dirty", "removed") - On a put(FQN): add or set FQN to the map, set status="dirty" - On a remove(FQN): set FQN in map to "removed", needs to mark all subnodes as well, so maybe the dirty-node map needs to be a tree... We might get rid of *constructing the modification lists during modifications*, and only populate the dirty-node map. The modification list could only be created at *TX commit time*, from the dirty-node map, e.g in the above example: PUT(a/b/c). This only applies to pessimistic locking (does it ? can't we optimize optimistic locking in similar ways ?)