NG
тогда рс + рз подходит
Size: a a a
2021 October 28
DK
РЗ не подходит
NG
сколько у вас пользователей, что вам РЗ не подходит?
DK
4000~
JD
Ну тогда РС + стартуешь из обработки проведения ФЗ, передаешь туда ссылку, внутри ФЗ ставишь упр. блокировку на запись РС и если дождался, то проверяешь что запись там есть, и уже отправляешь что и куда нужно
DK
Интересная мысль. Буду пробовать.
JD
Только это в плане нагруженности будет на порядки больше давать нагрузку на базу, чем РЗ в один поток. Поэтому чем РЗ не подходит это ты думаю сам себе стреляешь в коленку.
DK
Заказчик хочет, практически мгновенной реакции. Если регламентное задание будет выполняться каждую секунду, как мне кажется нагрузка будет больше.
NG
если он хочет практически мгновенной реакции, то отправляйте сообщение во вторую систему онлайн прямо в транзакции (пользователи вам тут тоже спасибо скажут за такие приколы конечно, но вы же быстро хотите), а потом фоново посылайте во вторую систему закрывающий тикет, что этот объект с этой версией данных можно коммитить
DK
Плюс, регламент будет выполняться и тогда, когда мне не нужно. Выгрузка касается одного конкретного вида документа, его записывают не так уж и часто.
JD
РЗ подхватит 1000 неотправленных с прошлого момента документов и будет отправлять их по одному.
Если захочешь - распараллелишь это дело в сколько нужно потоков и ограничишь.
В случае с мгновенной отправкой через ФЗ у тебя никак ограничить параллельность не получится - провели пользователи 1000 в секунду и оно породило 1000 ФЗ и у тебя кластер встал на какое-то время.
Если захочешь - распараллелишь это дело в сколько нужно потоков и ограничишь.
В случае с мгновенной отправкой через ФЗ у тебя никак ограничить параллельность не получится - провели пользователи 1000 в секунду и оно породило 1000 ФЗ и у тебя кластер встал на какое-то время.
JD
Неплохо переложил ответственность за отсутствие события "после успешной записи" на внешнюю систему :)
DK
У меня была мысль, включить документ в план обмена, в скуле повесить триггер на таблицу изменений и от него уже попробовать поймать событие.
JD
Что мешает в таком случае просто триггер на саму таблицу документа повесить?
DK
Или, так...
NG
Разве триггер учитывает коммит транзакции? Я думал, он прям в той же отрабатывает
А
А как транзакция работает если из нее вызывать фоновое задание с управляемой блокировкой?
JD
Ну ты в первой транзакции добавил что-то в РС - оно автоматом упр. заблокировалось до конца этой транзакции.
Внутри ФЗ уже встанешь в очередь за этой записью и если не дождался, значит первая транзакция еще идет (что маловероятно), а если дождался то уже читай эту запись и отправляй (а если прочитал и там ее нет, значит первая транзакция отменилась).
Внутри ФЗ уже встанешь в очередь за этой записью и если не дождался, значит первая транзакция еще идет (что маловероятно), а если дождался то уже читай эту запись и отправляй (а если прочитал и там ее нет, значит первая транзакция отменилась).
JD
Само ФЗ на первую транзакцию никак не влияет, если только ты не попытаешься еще раз перепровести этот же документ конечно, а ФЗ уже начало что-то делать (тогда уже клиент встанет в ожидание на заблокированном внутри ФЗ РС). Но и это решаемо.
DK
Вот из-за этого и триггер на таблицу изменений.