It has always been regarded as buggy and unmaintained and more of a
convenience for users coming from the old JBossCache.
If you are willing to help out, we can list the most important issues.
Tristan
On 20/02/17 19:22, Denis V. Kirpichenkov wrote:
> Hello.
>
> May I ask what's wrong with tree module?
>
> I work on a project which depends on this module heavily. I hope it is
> not a huge problem to reimplement tree module or at least some part of
> it if someone will tell me where to start :)
>
> --
>
> Denis
>
>
> On 20.02.2017 23:02, Sanne Grinovero 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.
>>
>> @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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
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
