Thanks, this is what I have ended up doing. However, it looks like AffinityKeyMapper is deprecated? I am adding an implementation of this (which returns the binary typename of the key BinaryObject) - and this does seem to have the desired effect (e.g. all keys with the same typename are marked as primary on a single node). I set this implementing class on the cache configuration.
I don't think I can use the suggested @AffinityKeyMapped annotation because we don't have a type representing the key that we can add this to. Our caches are created via table creation DDL with: WITH "TEMPLATE=MY_TEMPLATE,value_type=SOME_TABLE_TYPE, key_type=SOME_TABLE_KEY" The value and keys we operate on are all BinaryObjects. In terms of design, we have to have some sort of expectation of transactional safety. E.g. a user can update 2 records in a cache (e.g. some calculation inputs) which need to both be seen at the same time in order execute logic as they are updated. Could you please advise if: 1. There is an alternative to the deprecated AffinityKeyMapper we should be using instead? 2. What side effects there might be to having all keys marked as primary on a single node (even though the caches are marked as REPLICATED). 3. If there is any other more robust way of achieving this? 4. How we can tune the locallisten thread to be single threaded for a particular query. We want to eliminate any chance of a locallisten being hit in parallel for updates to the same cache (ideally without implementing our own synchronization). This seemed to happen in practice for singular updates on the cluster happening concurrently, but after setting the pageSize and timeInterval - these 3 updates from the 3 nodes seemed to come in concurrently. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
