AD
Причём как в рамках транзакции так и вне если мне не изменяет память
Size: a a a
2021 October 29
ZT
Всем привет! Кто может подсказать как произвольный макет использовать ПриКомпоновкеРезультата? Я Получил ТЗ , но дальше как корректно вывести данные в свой макет и на "ФормаОтчета"- БСП ?
FF
Так укажи свой макет основным
DK
Используем такой вариант. Сообщение отправляется мнгновенно. Управляемую блокировку ставим на сам документ, а не на запись РС
g
На случай если сообщение не уедет что делаете? Предположим связи с сервисом нет
VN
Авто от запрета отличается только ручным добавлением получателя.
Регистировать ссылку явно (как Никита писал), а не через получателя имхо плохо, костыльно и избыточно в случае отказов.
ПС: дежавю... Разобрали кейс два дня назад. Херак.. и все по новой)
Регистировать ссылку явно (как Никита писал), а не через получателя имхо плохо, костыльно и избыточно в случае отказов.
ПС: дежавю... Разобрали кейс два дня назад. Херак.. и все по новой)
DK
При записи документ регистрируется на узле. При фоновой отправке регистрация с узла удаляется.
Плюс еще периодически стартует РЗ, которое подбирает старые регистрации с узла и отправляет. Но это исключительные случаи.
Ну и бывают обмены, где потеря сообщения не страшна.
Плюс еще периодически стартует РЗ, которое подбирает старые регистрации с узла и отправляет. Но это исключительные случаи.
Ну и бывают обмены, где потеря сообщения не страшна.
g
Поэтому блокировка вам и не нужна, РС и план обмена немного разные вещи то
DK
Блокировка нужна нам. Мы по ней проверяем в фз завершилась ли транзакция записи, вызвавшая фз
VN
На что ставить блокировку - как бы без разницы. И там и там ссылка.
Разница вылезет, когда у вас появятся конкурирующие блокировки из других алгоритмов. Например, и две разные очереди, документ в каждой, обрабатываются отдельно.
Для этого и делается блокировка на отдельном пространстве.
Разница вылезет, когда у вас появятся конкурирующие блокировки из других алгоритмов. Например, и две разные очереди, документ в каждой, обрабатываются отдельно.
Для этого и делается блокировка на отдельном пространстве.
VN
Все верно. Только для этого и нужна блокировка.
Что РС, что регистрация в узле выполняют одну и ту же функцию: контроль аварии алгоритма и повторное выполненное. Если бы не аварии, то можно было бы и без очереди обойтись вообще)
Что РС, что регистрация в узле выполняют одну и ту же функцию: контроль аварии алгоритма и повторное выполненное. Если бы не аварии, то можно было бы и без очереди обойтись вообще)
ZT
в какой момент подскажи пожалуйста
DK
Исключительная блокировка при записи может быть только одна на документе. А при обработке в очереди ставится блокировка разделяемая. Очередей несколько , обрабатывают параллельно , друг с другом очереди обработки не конкурируют
VN
Имхо выбор между планом и РС очень простой. Нужна одна очередь - РС. Нужно отправлять в разные сервисы - можно делать дополнительное измерение в РС, но план для этого удобнее/логичнее.
VN
А если есть рз, подбирающее аварии + оперативное ФЗ, то как вы разделите обработку одной ссылки из очереди двумя потоками?
Можно конечно условие на таймштамп сделать... тогда разделяемая годится
Можно конечно условие на таймштамп сделать... тогда разделяемая годится
g
Одна очередь на разные сервисы?) чтобы потом пытаться объяснить отсутствия выгрузки в ТСД из-за того что мобильное приложение упало из-за интеграции интернет магазина?)
У нас всегда предпочтение в РС, планы обмена только с обменами на КД и на обмены с «ночной выгрузкой», для тех кто не спешит
У нас всегда предпочтение в РС, планы обмена только с обменами на КД и на обмены с «ночной выгрузкой», для тех кто не спешит
VN
По-моему я написал обратное
g
Значит я не правильно прочитал
VN
Одна очередь = один сервис.
А не все в куче
А не все в куче
g
