Currently my writethrough executes a stored procedure, but it has to identify
whether to insert or update which is inefficient as well as using locks and
transaction. If I disable write behind caching my cache put processing slows by
a factor of 10.
I'm thinking of adding a rowID field to the c
For CacheStore.write is there any need to lock in the database to prevent
simultaneous row updates? Presumably it’s quicker to lock the key at the cache
level and allow DB lock free and non-transactional updates?
John
From: Ilya Kasnacheev
Sent: Thursday, April 11, 2019 4:31 PM
To: user@ignite
Hi,
It's true that Ignite provides the implementation for JSR107:
https://ignite.apache.org/use-cases/caching/jcache-provider.html
https://apacheignite.readme.io/docs/jcache
Unfortunately, I don't have the details of how exactly it was implemented
and can't suggest you in your questions but Apac
Hi,
Yes without logs it's not easy to understand what is the reason. Could you
please attach them?
BR,
Andrei
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi,
This calculator provides the approximated results but I will try to explain:
1)Does it mean that I need to give or take 3GB of physical RAM on the host
and set OFF-HEAP value to 3GB?
Not fully correct. Yes, you should have 3GB of RAM for OFF-HEAP. But also
you should provide some memory for
Hi,
Here is a small example that works for me:
IgniteCache cache = grid(1).cache("person");
cache.put(1, new Person("sun", 100));
cache.put(2, new Person("moon", 50));
String sql =
"UPDATE person" +
" SET name = ?" +
Hello,
Feel free to use Ignite .NET for that. Moreover, you have 2 options here:
1. Use .NET standard client (supports most of the APIs but connects to
the cluster via a JVM process started internally). Here is how you can
define its config for entries eviction:
https://apacheignite-n
This shouldn't happen with the backups number set in your config and the
test you do. However, the PRIMARY_SYNC mode implies that an update/insert
will be replicated asynchronously to a backup node. It means that even
after the preloading is finished data still will be replicated from primary
to ba
I am trying to figure out how to set a cache value to a NULL. The update
is coming through and I am doing the following:
String sql =
"UPDATE MAIN.EXCHANGE" +
" SET LEGACYXRID = ?" +
" ,EXCHANGENAME = ?" +
After upgrading to Ignite 2.7 (via nuget) I get the following output
alongside the hang (I suspect this extra logging info is due to
IGNITE-6587):
PutAsync
Replace
Apr 12, 2019 8:56:09 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Blocked system-critical thread has been detected. Th
10 matches
Mail list logo