[jbosscache-issues] [JBoss JIRA] Updated: (JBCACHE-611) Optimize modification list before replication

[Manik Surtani (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBCACHE-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manik Surtani updated JBCACHE-611:
----------------------------------

    Fix Version/s:     (was: 3.0.0.GA)


> 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
>
> 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 ?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira