On Tue, Feb 21, 2017 at 5:36 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > On 21 February 2017 at 14:52, Dan Berindei <dan.berin...@gmail.com> wrote: >> On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero <sa...@infinispan.org> >> wrote: >>> On 21 February 2017 at 07:37, Dan Berindei <dan.berin...@gmail.com> wrote: >>>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero <sa...@infinispan.org> >>>> 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. >
I was assuming that we can suspend the current JTA transaction, start and commit a new transaction, then resume the pre-existing transaction. Dan _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
