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

[Mircea Markus (JIRA)]

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

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