Hi Colin,
I would suggest you send a new message to user list with a detailed
description of your use case, I think the community could check it and give
some comments.
Evgenii
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Benchmarks I've run on this flag and tests on mutating the entry
(acknowledging that this would be bad practice in production) - agree with
Evgenii's comments. Namely that this attribute has an effect for on-heap
caches (I'm using 2.1). I find it has more of an effect in cases where he
same
HI,I am using 1.9 and according to your explanation neither does it make sense to me. Thanks anyway for explaining the precise semantics. I will try to change some parameters of the tests to see if I can come up with some meaningful explanation.Thanks againSteve Original Message
Hi,
I want to clarify about usage copyOnRead=False:
As far as I know, It should help in 1.x releases, with the default
configuration, when entries stored in onheap and in 2.x releases, with
onHeapCacheEnabled=true(it's not default). I think we should mention this
in the documentation.
Also, it
Hello,
thanks for the answer. The benchmark is actually our application stressed
with several volumes. Some quite complex to describe. However, for these
benchmarks we are only using one node.
Basically we are loading a set of caches from the database, do a lot of
querying both ScanQuery (on
Hi,
Could you describe your benchmarks? So we can understand whats could be
wrong here.
If the value is fetched from a remote node, you will always get a copy. If
you get the value locally, you can force Ignite to return the stored
instance by setting CacheConfiguration.setCopyOnRead(false)
