[ https://issues.jboss.org/browse/ISPN-1988?page=com.atlassian.jira.plugin.... ] Manik Surtani commented on ISPN-1988: ------------------------------------- The immediate benefit of coalescing is, as described above, to bypass the reordering of optimistic lock acquisition if only one key is ever locked. But doing this by iterating over the set of WriteCommands in the transaction is almost as expensive. So here's a proposal. Only if cluster size > 1 and optimistic transactions are used: 1. A subclass of the LocalTransaction (on the transaction originator) contains a boolean, {{targetForCoalescing}}, set to {{false}} initially. 2. The first time the EntryWrappingInterceptor wraps a key and puts it in the context, set {{targetForCoalescing}} to {{true}}. 3. For any subsequent calls in the EntryWrappingInterceptor, if we get a new entry from the DataContainer and wrap it, set {{targetForCoalescing}} to {{false}} again. 4. Before broadcasting a PrepareCommand in the DistributionInterceptor or ReplicationInterceptor, if {{targetForCoalescing}} is {{true}} and number of WriteCommands > 1, coalesce the write set since there is a high chance that there is benefit to doing this. There may be other benefits to coalescing write sets which touch > 1 key too, but that is more complex to detect reliably whether coalescing will provide any benefits before actually performing the coalescing (iterating over the write set). So we should start with the first scenario since this will definitely be a significant boost for anyone using AtomicMaps (Hibernate OGM and JBoss AS for example). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1988?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-1988 at 4/20/12 6:02 AM: -------------------------------------------------------------- I like the idea of making coalescing a dynamic thing (vs a global config) as it is more efficient and cheap to calculate. Re: the algorithm, the logic at 3 would invalidate coalescing in the following situation: start tx put k, v1 put k, v2 put k, v3 put k2, v4 //this put would set coalescing to false and we don't really want that!!! commit We would do better in the EntryFactoryImpl: if we are wrapping an entry for write and the entry is already in the context with {{isChanged}} set to true then we {{targetForCoalescing}}. In other words if me detect that an entry was modified twice within the scope of the same transaction we mark it for coalescing. was (Author: mircea.markus): I like the idea of making coalescing a dynamic thing (vs a global config) as it is more efficient and cheap to calculate. Re: the algorithm, the logic at 3 would invalidate coalescing in the following situation: start tx put k, v1 put k, v2 put k, v3 put k2, v4 //this put would set coalescing to false and we don't really want that!!! commit We would do better in the EntryFactoryImpl: if we are wrapping an entry for write and the entry is already in the context with {code}isChanged{code} set to true then we {code}targetForCoalescing{code}. In other words if me detect that an entry was modified twice within the scope of the same transaction we mark it for coalescing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira