On Wed, Feb 22, 2017 at 10:53 AM, Radim Vansa wrote:
> On 02/22/2017 09:11 AM, Dan Berindei wrote:
>> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote:
>>> On 02/21/2017 07:14 PM, Dan Berindei wrote:
But doesn't the functional API's evalMany() provide
On 02/22/2017 09:53 AM, Radim Vansa wrote:
> On 02/22/2017 09:11 AM, Dan Berindei wrote:
>> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote:
>>> On 02/21/2017 07:14 PM, Dan Berindei wrote:
But doesn't the functional API's evalMany() provide something very
close to
On 02/22/2017 09:11 AM, Dan Berindei wrote:
> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote:
>> On 02/21/2017 07:14 PM, Dan Berindei wrote:
>>> But doesn't the functional API's evalMany() provide something very
>>> close to the API you're suggesting?
>>>
>>> Dan
>>>
>>>
On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa wrote:
> On 02/21/2017 07:14 PM, Dan Berindei wrote:
>> But doesn't the functional API's evalMany() provide something very
>> close to the API you're suggesting?
>>
>> Dan
>>
>>
>> On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa
On 02/21/2017 07:14 PM, Dan Berindei wrote:
> But doesn't the functional API's evalMany() provide something very
> close to the API you're suggesting?
>
> Dan
>
>
> On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote:
>> On 02/21/2017 05:16 PM, Tristan Tarrant wrote:
>>> On
But doesn't the functional API's evalMany() provide something very
close to the API you're suggesting?
Dan
On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote:
> On 02/21/2017 05:16 PM, Tristan Tarrant wrote:
>> On 21/02/17 16:29, Sanne Grinovero wrote:
You haven't
On 02/21/2017 05:16 PM, Tristan Tarrant wrote:
> On 21/02/17 16:29, Sanne Grinovero wrote:
>>> You haven't explained what "flush" means. Since you separate that from
>>> atomicity/consistency, I assume that batches on non-tx cache are just
>>> ordered putOrRemoveAll operations, immediately visible
On 21/02/17 17:59, Sanne Grinovero wrote:
> On 21 February 2017 at 16:16, Tristan Tarrant wrote:
>> On 21/02/17 16:29, Sanne Grinovero wrote:
You haven't explained what "flush" means. Since you separate that from
atomicity/consistency, I assume that batches on
On 21 February 2017 at 16:16, Tristan Tarrant wrote:
> On 21/02/17 16:29, Sanne Grinovero wrote:
>>> You haven't explained what "flush" means. Since you separate that from
>>> atomicity/consistency, I assume that batches on non-tx cache are just
>>> ordered putOrRemoveAll
On 21/02/17 16:29, Sanne Grinovero wrote:
>> You haven't explained what "flush" means. Since you separate that from
>> atomicity/consistency, I assume that batches on non-tx cache are just
>> ordered putOrRemoveAll operations, immediately visible on flush without
>> any atomicity.
I assume that
On 21 February 2017 at 14:52, Dan Berindei wrote:
> On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero
> wrote:
>> On 21 February 2017 at 07:37, Dan Berindei wrote:
>>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero
On 21 February 2017 at 13:20, Radim Vansa wrote:
> On 02/21/2017 09:39 AM, Sanne Grinovero wrote:
>> On 21 February 2017 at 07:37, Dan Berindei wrote:
>>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero
>>> wrote:
-1 to
On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero wrote:
> On 21 February 2017 at 07:37, Dan Berindei wrote:
>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero
>> wrote:
>>> -1 to batch removal
>>>
>>> Frankly I've always
On 02/21/2017 09:39 AM, Sanne Grinovero wrote:
> On 21 February 2017 at 07:37, Dan Berindei wrote:
>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero
>> wrote:
>>> -1 to batch removal
>>>
>>> Frankly I've always been extremely negative about the
Hi Denis,
recently I had to disable test for move() operation in pessimistic cache
[1] because the way move is implemented cannot work. I'll be happy to
consult possible fix (please use another thread for that).
For the record, this is not exhaustive list of problems, I haven't
touched tree
On 21 February 2017 at 07:37, Dan Berindei wrote:
> On Mon, Feb 20, 2017 at 8:02 PM, 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
+1 to remove the async transactional modes
+1 to remove batching
I'm ambivalent about the tree module. I think we should be able to get
it on a better footing by using the transactions API, but I'm unsure
about the amount of work needed.
The biggest problem with the tree module and batching, as
On Mon, Feb 20, 2017 at 8:02 PM, 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,
Tristan, yes, I'd like to help.
And the list of issues with this module would be something to start with.
Thanks.
--
Denis
On 21.02.2017 01:13, Tristan Tarrant wrote:
> It has always been regarded as buggy and unmaintained and more of a
> convenience for users coming from the old JBossCache.
On 20 February 2017 at 20:11, Tristan Tarrant wrote:
> On 20/02/17 19: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.
>
> I think the discussion is pointless
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
On 20/02/17 19: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.
I think the discussion is pointless without clearing up what the
expected semantics of a batch should be and what the
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,
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
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
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
- Remove the tree module: it doesn't work properly, and uses
27 matches
Mail list logo