Pedro’s suggestion looks good [1]
It’s passed tests both locally (20 threads, each sending 200 operations) and in
a remote server (40 threads, each sending 1000 operations).
Cheers,
[1] https://github.com/infinispan/infinispan/pull/2671
On 25 Jun 2014, at 10:21, Galder Zamarreño wrote:
>
>
On 24 Jun 2014, at 19:51, Pedro Ruivo wrote:
>
>
> On 06/24/2014 05:11 PM, Mircea Markus wrote:
>>
>> On Jun 24, 2014, at 16:50, Galder Zamarreño wrote:
>>
>>>
>>> On 24 Jun 2014, at 16:51, Mircea Markus wrote:
>>>
On Jun 24, 2014, at 15:27, Galder Zamarreño wrote:
On 25 Jun 2014, at 08:45, Dan Berindei wrote:
>
>
>
> On Tue, Jun 24, 2014 at 9:04 PM, William Burns wrote:
> I must admit this seems a bit heavy handed to have to enable
> transactions, when are using them solely for the purpose of having
> implicit transactions.
>
> Can we not instead jus
FYI: Takayoshi has run some further testing and found that with 40 threads
there was still some deviation, so it needs further investigation.
On 24 Jun 2014, at 16:27, Galder Zamarreño wrote:
> Hi all,
>
> Last few days I’ve been having fun fixing [1] and the solution I’ve got to
> has some l
On Tue, Jun 24, 2014 at 9:04 PM, William Burns wrote:
> I must admit this seems a bit heavy handed to have to enable
> transactions, when are using them solely for the purpose of having
> implicit transactions.
>
> Can we not instead just tweak the NonTransactionalLockingInterceptor
> to obey the
I must admit this seems a bit heavy handed to have to enable
transactions, when are using them solely for the purpose of having
implicit transactions.
Can we not instead just tweak the NonTransactionalLockingInterceptor
to obey the FORCE_WRITE_LOCK, so it would guarantee a consistent value
in the
On 06/24/2014 05:11 PM, Mircea Markus wrote:
>
> On Jun 24, 2014, at 16:50, Galder Zamarreño wrote:
>
>>
>> On 24 Jun 2014, at 16:51, Mircea Markus wrote:
>>
>>>
>>> On Jun 24, 2014, at 15:27, Galder Zamarreño wrote:
>>>
To fix this, I’ve been working with Dan on some solutions and we’ve
On Jun 24, 2014, at 16:50, Galder Zamarreño wrote:
>
> On 24 Jun 2014, at 16:51, Mircea Markus wrote:
>
>>
>> On Jun 24, 2014, at 15:27, Galder Zamarreño wrote:
>>
>>> Hi all,
>>>
>>> Last few days I’ve been having fun fixing [1] and the solution I’ve got to
>>> has some links to [2].
>>
On 24 Jun 2014, at 16:51, Mircea Markus wrote:
>
> On Jun 24, 2014, at 15:27, Galder Zamarreño wrote:
>
>> Hi all,
>>
>> Last few days I’ve been having fun fixing [1] and the solution I’ve got to
>> has some links to [2].
>>
>> The problem is that when getCacheEntry() is called, the entry
On Jun 24, 2014, at 15:27, Galder Zamarreño wrote:
> Hi all,
>
> Last few days I’ve been having fun fixing [1] and the solution I’ve got to
> has some links to [2].
>
> The problem is that when getCacheEntry() is called, the entry returned could
> be partially correct. Up until now, we’d sen
Hi all,
Last few days I’ve been having fun fixing [1] and the solution I’ve got to has
some links to [2].
The problem is that when getCacheEntry() is called, the entry returned could be
partially correct. Up until now, we’d send back a cache entry back to the
client that the user could not mod
11 matches
Mail list logo
