On 21/02/17 17:59, Sanne Grinovero wrote: > 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.
Why I thought that putIfAbsent might not be appropriate I don't know. It makes perfect sense. Even the replace ops. -- 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
