Apache Ignite c++ client 2.16. with Transactions - IGNITE_ERR_TX_THIS_THREAD Issue

Question

My application is multithreaded and i have multiple instances of application running, which is triggering getAll on the same cache for different set of keys using transactions.

The Apache Ignite is throwing "Transaction already started by current thread IGNITE_ERR_TX_THIS_THREAD = 2027." Error.

My app does the following.

1. Inserts the message
2. Check if it received all the messages (since other instances are also inserting) checking the ContainsKey(KeySets)
3. if so, creates a transaction, gets all the messages (getAll) and stores in the application data structure for further processing and removes all from the cache and commits the transatction. This is needed because only 1 instance of application should get all the messages. or else, it gets the duplicates. Also have a retry mechanism if there is any transaction errors.

Since the step 3 is happening frequently for different set of keys on the same cache, I think the Ignite is throwing IGNITE_ERR_TX_THIS_THREAD error. Is there a better approach to handling this error ?

I tried increasing the StripedPoolSize but still getting the same error.

Answer 1

Wow! There are so many items to discuss here.

1. Anytime I hear about inserting and then removing entries from a cache I immediately start to worry about things like memory growth & compaction issues. Is there another way to address this instead of insert / delete?
2. You stated that you are multi-threaded where different threads address different messages (keys). Are these different messages (keys) in different partitions? If not you are likely architected for inherent locking or delays due to transaction contention on the same partitions?
3. Lastly your description of item three is in no way clear. You start a transaction, getAll, update something, then remove all? Sorry but I would not be able to provide any advice on that as the multiple uses of "all" is in no way discernable what is being gotten, vs updated, removed. One thing that might help (I can't say for sure) is to consider the use of different caches? One cache for figuring out that you have the right keys in place. Then a second cache to store the final results for the right keys. This might reduce transaction contention as your TX for the final state of the second cache should be quick as you know the exact keys and the exact data. Hope that helps.