[infinispan-issues] [JBoss JIRA] (ISPN-1988) Coalesce updates to a given key to a single operation within a transaction

[Manik Surtani (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12685157#comment-12685157 ] 

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).
                
> Coalesce updates to a given key to a single operation within a transaction
> --------------------------------------------------------------------------
>
>                 Key: ISPN-1988
>                 URL: https://issues.jboss.org/browse/ISPN-1988
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 5.1.4.FINAL
>            Reporter: Mircea Markus
>            Assignee: Mircea Markus
>              Labels: optimisation, transaction
>             Fix For: 5.2.0.FINAL
>
>
> Following code run with optimistic caches:
> start tx
> put k, v1
> put k, v2
> put k, v3
> commit
> Would cause the PrepareCommand that is sent around to contain 3 PutKeyvalueCommands which is sub-optimal. What we can do is to only send the last written value (i.e. k v3) and ignore the previous two (reuse the code in AsyncCacheStore). Besides reducing the payload, from this would benefit the AtomicHashMaps which uses this code quite a lot and also the OptimisticLockingInterceptor which would not attempt to order the keys.
> I guess this should be a feature that is disabled by default, as I don't think it is required in general. Might as well be not configurable, enabled by default feature. Comments? 

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