"Но мы не можем написать некоторые триггеры в sql."
Это единственный возможный способ, если вы хотите, чтобы ваша система была надежной, и если вы хотите, чтобы она постоянно предоставляла правильную информацию своим пользователям (и, если возможный способ есть - см. Далее) .
Кто-то ответил: «App1 отправляет сообщение в App2», на что было дано замечание «Не соответствует ACID». Замечание является верным (учитывая некоторую разумную интерпретацию термина «КИСЛОТА»). Дело в том, что ваше приложение2 хочет получать, скажем, уведомления о вставке, в тот момент, когда абсолютно точно , что вставка действительно произошла. Эта точка уверенности достигается только тогда, когда СУБД имеет , успешно зафиксировало такую вставку.
Следовательно, триггер, который вам нужен, является своего рода триггером, который запускается после удачного коммита (существуют ли они?).
И тогда возникает проблема: что должно произойти с зафиксированными данными, если по какой-либо причине этот триггер завершится неудачно? Ваши данные зафиксированы, ваше приложение 1 считает, что все в порядке, но ваше приложение 2 все еще не получило уведомление, которое должно было быть получено.
Решение этой проблемы состоит в том, что ваше приложение1, а также ваша СУБД и ваше приложение2 должны быть готовы к двухэтапной фиксации. Я не сомневаюсь, что, поскольку вы «не можете ничего сделать с app1», вы также не сможете заставить его участвовать в 2PC.
Шаблон "слушатели базы данных" - это простой и некорректный дизайн. По крайней мере, если вы дорожите «абсолютной последовательностью».