Cache");
>>>>>>>>>>>>> //Sequence number for guid
>>>>>>>>>>>>> IgniteAtomicSequence guidSeq = getGuidSeq(ignite,
>>>>>>>>>>>>> targetCache);
>>>>>
tionService(targetCache, guidSeq);
>>>>>>>>>>>> //load staging
>>>>>>>>>>>> loadStaging(stagingCache);
>>>>>>>>>>>>
>>>>>>>>>>>> //p
gt;> SqlQuery<>(StagingRec.class, getStagingSql());
>>>>>>>>>>> try (QueryCursor<Cache.Entry<String, StagingRec>>
>>>>>>>>>>> cursor = stagingCache.query(sqlStg)) {
>>>>>>>>>>>
>>
for (Cache.Entry<String, StagingRec> e : cursor) {
>>>>>>>>>> Transaction tx =
>>>>>>>>>> txs.txStart(TransactionConcurrency.PESSIMISTIC,
>>>>>>>>>> TransactionIsolation.REPEATABLE_READ
e.processStaging(e);
>>>>>>>>> //stagingCache.remove(e.getKey()); //remove entry
>>>>>>>>> from staging
>>>>>>>>> tx.commit();
>>>>>>>>> }
gt;>>> }
>>>>>>>>
>>>>>>>> In service.processStaging, the logic looks like this:
>>>>>>>>
>>>>>>>> if (condition1) {
>>>>>>>> targetCache.put(key, valu
targetCache.put(key, value);
>>>>>>> } else if (condition2) {
>>>>>>> targetCache.remove(key, value);
>>>>>>> targetCache.put(key2, value2);
>>>>>>> }
>>>>>>>
>>>>>>> Do you s
ov-2 [via Apache Ignite
>>>>>> Users] <[hidden email]
>>>>>> <http:///user/SendEmail.jtp?type=node=11827=0>> wrote:
>>>>>>
>>>>>>> Could you share code snippet which your benchmarked?
>>>>>>&
the first cache as input
>>>>>>> and output value to the second cache.
>>>>>>>
>>>>>>> The first cache has readThrough only.
>>>>>>>
>>>>>>> Part of the configurations for second caches are below:
indexes on this cache.
>>>>>
>>>>> The other case is to set writeThrough and writeBehindEnabled to false.
>>>>> I didn't change other settings.
>>>>> Is there anything else that might be relevant to this case?
>>>>>
>>>&
ai Tikhonov-2 [via Apache Ignite
>>>> Users] <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node=11792=0>> wrote:
>>>>
>>>>> It's strange. Could you share your configuration for both case? Also
>>>>> could you de
;>> It's strange. Could you share your configuration for both case? Also
>>>> could you describe more your case?
>>>>
>>>> On Wed, Apr 5, 2017 at 8:45 PM, waterg <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node=11789=
PM, waterg <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node=11789=0>> wrote:
>>>
>>>> Thank you for the reply.
>>>> Yes, I disabled both write through and write behind.
>>>> We're trying evaluate the application's perfor
disabled both write through and write behind.
>>> We're trying evaluate the application's performance on ignite and by
>>> taking
>>> the persistent store out of equation, we thought the performance shall
>>> improve, but on the contrary we saw performance drop
this kind of behavior?
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Disable-WriteBehind-tp11729p11763.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>
>
>
s message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Disable-WriteBehind-tp11729p11763.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
would
explain this kind of behavior?
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Disable-WriteBehind-tp11729p11763.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Seems I misunderstood your question. Did you disable both writeThrough and
writeBehind properties and got worse perfomance?
On Wed, Apr 5, 2017 at 4:39 PM, Nikolai Tikhonov <ntikho...@apache.org>
wrote:
> Hi,
>
> Yes, it's expected behavior. If you disable writeBehind t
Hi,
Yes, it's expected behavior. If you disable writeBehind then each update
will be propagated in underlying a store immediately and it's impact to
performance. You can find more details in docs [1].
1.
https://apacheignite.readme.io/docs/persistent-store#section-write-behind-caching
On Wed
this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Disable-WriteBehind-tp11729.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
20 matches
Mail list logo
