QueryCursor checkpoint
Hello, Our end production cluster would be working with many billions of entities in many caches, and have use cases where we need to run ScanQuery over an entire cache to update certain fields. We expect that there could definitely be failures in the middle of a single ScanQuery due to the sheer size of the caches. Since we wouldn't want to rerun ScanQuery from the start, we're wondering if we could keep some checkpoint of up to which point we've processed in the QueryCursor. The QueryCursor API doesn't seem to show any methods that allow that, but I may not be looking at the right place? Would there be any other efficient ways to keep track of vaguely up to which point we've processed? If QueryCursor doesn't provide anything externally, would partition number be the best option? But from what I've seen, it seemed like entities in partitions shift around (from rebalancing or something?), so not sure if that's even possible. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Transactional cache in Atomic mode
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 implicit transaction works the same implementation-wise as the ATOMIC mode, implicit should be much faster as noted in the Ignite documentation as well. Unfortunately, there seems to be very little documentation on how the implicit transaction works. What is its TransactionConcurrency and TransactionIsolation modes? 2) I think by the definition of how explicit transaction should work, entry-level locking is unlikely for explicit transaction (perhaps it's only for atomic-mode or implicit?). Explicit transaction groups multiple cache operations and since we also make it PESSIMISTIC and SERIALIZABLE, it seems highly likely to lock on a larger granularity than an entry to prevent other operations from accessing or writing to any of those caches we operate on. I presume the locking behavior and granularity would change based on the transaction, TransactionConcurrency, and TransactionIsolation. Do you know how the locking schema changes based on each of the choices for the modes? I don't think there's any documentation available. Here is a portion of the stacktrace which may or may not be useful. Caused by: class org.apache.ignite.transactions.TransactionTimeoutException: Failed to acquire lock within provided timeout for transaction [timeout=6, tx=GridNearTxLocal[xid=a7a36ec5861--097d-8e11--0001, xidVersion=GridCacheVersion [topVer=159223313, order=1547746818682, nodeOrder=1], concurrency=PESSIMISTIC, isolation=SERIALIZABLE, state=ACTIVE, invalidate=false, rollbackOnly=false, nodeId=78a6e3af-19e6-4b62-831e-fd27f1478afb, timeout=6, duration=61497]] at org.apache.ignite.internal.util.IgniteUtils$13.apply(IgniteUtils.java:899) at org.apache.ignite.internal.util.IgniteUtils$13.apply(IgniteUtils.java:894) ... 27 more -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: ignite_backup_restore_query
Are there any additional steps to take after 4. start cluster again to ensure that ignite recognizes the new data? I've attempted several times to copy the data and wal directory (and making sure that the consistent ID are the same) into a new node, but when looking through visor, all the caches indicate that there are 0 entries ingested. It just doesn't seem to be picking up that there are manually copied data in the persistence storage directory. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Transactional cache in Atomic mode
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/
Transactional cache in Atomic mode
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 do a logical operation on a group of caches. However, there are cases we want to have ATOMIC operations on a single cache to increase performance. What I'm wondering is: if a cache is set to operate on a TRANSACTIONAL mode, does it always need to be operated inside the IgniteTransactions transactions = ignite.transactions(); Java transaction API? Would the changes simply not commit if we were to update the cache without surrounding it inside this IgniteTransactions context? 2) To increase performance of a ScanQuery over a test cache of ~1million entries, I have set up a ThreadPool of 10 threads to perform ScanQuery over each partition - where each thread would take over each partition - in a cluster that has a single server node. Each transaction had a commit size of 100k. However the entire operation failed because the threads could not acquire the lock for the transaction, and the transactions of other threads timed-out. What is the locking granularity for each transaction (seems like it locks the entire cache from what I've witnessed)? Is it possible to change the locking level so that I can set the transaction to lock on a partition or any other granularity? Thanks -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
