-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.
@Pedro: the fact that some code is broken today is not relevant, when
there's need for such features. Like you suggest, it had bad premises
(build it on TX) so we should address that, but not throw it all out.
@Bela is making spot-on objections based on use cases, which need to
be addressed in some way. The "atomical" operations still don't work
right[1] in Infinispan and that's a big usability problem.
+1 to remove async TX
I actually like the concept but the API should be different.. might as
well remove this for now.
+1 to remove the Tree module
I personally never used it as you all advised against, yet it's been
often requested by users; sometimes explicitly and others not so
explicit, yet people often have need which would be solved by a good
Tree module.
I understand the reasons you all want to remove it: it's buggy. But I
believe the real reason is that it should have been built on top of a
proper batch API, and using real MVCC. In that case it wouldn't have
been buggy, nor too hard to maintain, and might have attracted way
more interest as well.
I'd remove it as a temporary measure: delete the bad stuff, but
hopefully it could be reintroduced built on better principles in some
future?
Thanks,
Sanne
[1] - "right" as in user expectations and actual practical use, which
is currently different than in the twisted definition of "right" that
the team has been using as an excuse ;-) I'll also proof that it
doesn't work right according to your own twisted specs, when I find
the time to finish some tests..
On 20 February 2017 at 16:48, Pedro Ruivo <pe...@infinispan.org> wrote:
>
>
> On 20-02-2017 16:12, Bela Ban wrote:
>>
>>
>> On 20/02/17 17:06, Tristan Tarrant wrote:
>>> Hi guys, we discussed about this a little bit in the past and this
>>> morning on IRC. Here are some proposed removals:
>>>
>>> - Remove the async transactional modes, as they are quite pointless
>>> - Remove batching: users should use transactions
>>
>> How do you make a bunch of modifications and send them asynchronously if
>> both batching *and* async TXs are getting removed?
>
> We are not removing features, we are removing broken code.
>
> Batching is using transactions and async transactions doesn't make sense
> since infinispan has to report to TransactionManager.
>
> Our current asyn-tx is broken in a way that is starts to commit and
> reports OK to the transaction manager. if you have a topology change or
> a conflict, you will end with inconsistent data.
>
> So, why do we keeping this code around?
>
> you can still move a transaction commit to another thread if you don't
> wanna wait for its commit:
>
> tm.begin()
> doWork()
> tx = tm.suspend()
> new_thread {
> tm.resume(tx)
> tm.commit()
> }
>
> The best thing I can think of is to keep the batching API and
> re-implement it to provide an endBatchAsync() that will do the above.
>
>>
>> So if someone wants to apply a unit of work *atomically* (either all
>> modifications within that unit of work are applied, or none), what
>> alternatives exist?
>>
>>> - Remove the tree module: it doesn't work properly, and uses batching
>>>
>>> Please cast your votes
>>>
>>> Tristan
>>>
>>
> _______________________________________________
> 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
