Проверка, все ли QueryCaches получили обновления от IMap в кластере Hazelcast

Question

Имея кластер Hazelcast, как мне убедиться, что изменения, внесенные в IMap, полностью распространяются на QueryCaches на всех узлах кластера, прежде чем я вызову EntryProcessor, который использует измененные данные изте QueryCaches?

Упрощенный сценарий того, что я пытаюсь достичь:

• У меня есть алгоритм, который переоценивает элементы на основе некоторых параметров
• Тамдо одного миллиарда элементов, поэтому они хранятся в IMap
• В IMap
• Приходит запрос к приложению, изменить пару параметров и переоценить все элементы
• Параметры изменяются простым map.put(), затемалгоритм в форме EntryProcessor вызывается для элементов на каждом узле
• Это не будет работать, так как обновления QueryCache являются асинхронными, поэтому иногда алгоритм будет использовать старые значения параметров

public void handleRevaluationRequest(Object parametersChangeInstructions) {
    TransactionContext transaction = hazelcastInstance.newTransactionContext();
    transaction.beginTransaction();
    TransactionalMap parameters = transaction.getMap("parameters");
    parameters.set(...); // changes to a few parameters
    parameters.put(...); // adding a few different parameters
    transaction.commitTransaction();

    IMap items = hazelcastInstance.getMap("items");
    items.executeOnEntries(new RevaluationProcessor());
    // processor uses new and/or existing parameters from QueryCache to revalue items
    // but won't always see the changes to parameters that we've just made
}

Есть ли способ достичь чего-то подобного?Возможно, вместо QueryCache использование другой структуры данных будет более целесообразным для достижения синхронной «репликации» справочных данных, которые могут использоваться EntryProcessor.

Answer 1

Когда вы делаете map.put и запускаете EntryProcessor впоследствии, EP запускается в хранилище значений ключей на стороне сервера, поэтому он всегда работает с последним обновленным значением на сервере.Обновление до QueryCache через map.put является асинхронным и не связано с тем, что вы делаете в EntryProcessor и когда.

Кроме того, для вашей информации, EntryProcessor работает в потоке разделов, что означает, что поток, отвечающий за обновление значения, также отвечает за запуск EntryProcessor.Поэтому, пока работает EntryProcessor, никакой другой поток не может обновить это значение.