Hi Mikhail,
Thank you for your response.
1) From my testing, a ScanQuery of 1 million entries in an explicit
transaction (with PESSIMISTIC, SERIALIZABLE) took 10 minutes
single-threaded, whereas implicit transaction took 1 minute with the same
environment and single-threaded. If we assume that im
>1)
Batching always works better, however, I would benchmark single update vs
batch update to prove this.
>Would ignite itself make the implicit transaction /only if/ the explicit
JAVA API for transaction has not been called?
Right, if there's no definition for the transaction, there will be an
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 explicitl
Hi
>1)
you can do all operations on transaction caches without defining an explicit
transaction.
However, even if you don't start transaction and for example put some data
in transactional cache, ignite itself will make implicit transaction, so
transactionCache.put("key", "value") -> will update y
Hi,
Two questions about transactionality and locking:
1) I've been looking at https://apacheignite.readme.io/docs/transactions and
couldn't get a clear answer from the Ignite documentation so I hope to get
an answer here.
All of the caches we use are set to TRANSACTIONAL, as we will often need to