Я новичок в Stackoverflow, даже если я решил много проблем с вашими подсказками. Теперь у меня проблема, решения которой я не нашел. Я разрабатываю службу отправки с использованием WSO2 CEP и GCM. CEP обрабатывает запросы на подписку / отказ от подписки и push-события. Ключи подписок хранятся на моем собственном сервере с использованием MySQL вместе с другой информацией. Мои проблемы связаны с этапом подписки. Этот шаг должен обрабатывать либо новые подписки (вставка), либо существующую подписку (обновление). Чтобы упростить операцию, я решил нормализовать две операции, удалив и вставив записи (даже если запись уже может быть в БД). Чтобы справиться с этим, я разработал план выполнения, используя Сиддхи. План определяет 2 потока: поток событий и поток таблицы, связанный с таблицей MySQL. В плане выполнения сначала выполняется удаление с использованием ключа, взятого из события, а после вставки новой записи с использованием информации, содержащейся в событии. Но похоже, что последовательность операций (удаление и вставка) различается, поэтому иногда я обнаруживал на своем сервере две или более записей с одним и тем же ключом GCM. Я применил обходной путь, добавив уникальное ограничение для таблицы, но мне хотелось бы знать, есть ли способ исправить детерминированный порядок операций Сиддхи.
С Уважением
Мишель де Роса
