On 21 February 2017 at 16:16, Tristan Tarrant <ttarr...@redhat.com> wrote: > On 21/02/17 16:29, Sanne Grinovero wrote: >>> You haven't explained what "flush" means. Since you separate that from >>> atomicity/consistency, I assume that batches on non-tx cache are just >>> ordered putOrRemoveAll operations, immediately visible on flush without >>> any atomicity. > > I assume that in Sanne's idea, ordering in a batch doesn't matter, aside > from operations on the same key. Having ordering in there would for > example not allow us to parallelize by segment. > >> So I want to write a first chunk, in our code that looks like: >> >> startBatch >> put(chunk1/A, [some large value]) >> put(chunk1/B, [some small metadata]) >> put(chunk1/C, [some small metadata]) >> endBatch >> There is no reason to use a transaction, in fact we had to disable >> transactions as some of these entries could be large. >> There also is no reason for the batch, other than optimising the latency. > Let me summarize to see if we have the requirements for a useful > batching system (which is sort of patterned on the JDBC statement batching): > > - a batch is not an atomic operation, i.e. it is not backed by a transaction > - it can be wrapped in a transaction if needed > - batches cannot be nested > - batches only involve unconditional write operations (put, putAll, remove) > - ordering of operations within a batch is unimportant aside from > modifications to the same key where we apply "last one wins" > - when a batch is "flushed" (i.e. endBatch is invoked) the ops are > grouped by segment and sent to the appropriate owner for processing, > potentially in parallel > > As Radim has called it, this is essentially a putOrRemoveAll op (with an > async counterpart). > > Is that summary correct ?
Yes! Thanks BTW I don't fully subscribe that conditional operations shouldn't be considered, but I'm happy to keep that pandora box for another time. Remember optimistic transactions are useful in some cases. > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
