Re: [infinispan-dev] Major version cleaning

On 21 February 2017 at 14:52, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >> On 21 February 2017 at 07:37, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >>>> -1 to batch removal >>>> >>>> Frankly I've always been extremely negative about the fact that >>>> batches are built on top of transactions. It's easy to find several >>>> iterations of rants of mine on this mailing list, especially fierce >>>> debates with Mircea. So I'd welcome a separation of these features. >>>> >>>> Yet, removing batching seems very wrong. I disagree that people should >>>> use Transactions instead; for many use cases it's overkill, and for >>>> others - and this is the main pain point I always had with the current >>>> design - it might make sense to have a batch (or more than one) within >>>> a transaction. >>>> I have had practical problems with needing to "flush" a single batch >>>> within a transaction as the size of the combined elements was getting >>>> too large. That doesn't imply at all that I'm ready to commit. >>>> >>> >>> WDYM by "flush" here? I have a feeling this is nothing like our >>> batching ever was... >> >> I'm just listing points about why incorporating the batch concept with >> transactions is not practical. >> >> I mean that when one has to write very large amounts of data, you need to >> break it up in smaller batches; *essentially* to flush the first batch before >> starting the second one. >> So that is unrelated with atomicity and consistency, as in practice one has >> to split one business operation into multiple batches. >> > > Kind of repeating Radim's question, but how is this better than having > multiple small transactions and committing each one separately? If you assume that code integrating with Infinispan is in control of the transaction boundaries - for example able to decide when it's time to commit - it implies you can not integrate with other transactional components. Which defeats the purpose of exposing JTA integration.