Hi Mikhail,
Thanks for your answer.
1) So if Ignite implicitly puts each cache update in a transaction, does
that mean it's just better performance-wise to wrap 100k updates in a
transaction (We found that 100k was the optimal number of updates to do in a
single transaction) than to not explicitly put the updates in a transaction?
Would ignite itself make the implicit transaction /only if/ the explicit
JAVA API for transaction has not been called?
2) I should've stated it more clearly. So I was testing code structured like
this:
ExecutorService executor = Executors.newFixedThreadPool(10);
for (each partition p in node) {
executor.execute(
try(Transaction tx =
ignite.transactions().txStart(..)) {
update the entires in p
}
)
}
So we're wondering what the locking granularity is when we enter an
explicitly called transaction. Does it lock on partition, node, entry, or
something else? And is this configurable for each execution?
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
