[infinispan-dev] Major version cleaning

[Dan Berindei]

On Tue, Feb 21, 2017 at 5:36 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> On 21 February 2017 at 14:52, Dan Berindei <dan.berindei at gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero <sanne at infinispan.org> wrote:
>>> On 21 February 2017 at 07:37, Dan Berindei <dan.berindei at gmail.com> wrote:
>>>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero <sanne at 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