Изменения документа Про передачу сигнала на процесс

Сводка

• Свойства страницы (1 изменено, 0 добавлено, 0 удалено)

Подробности

Свойства страницы

Содержимое

...	...	@@ -5,39 +5,32 @@
5	5	|(% style="width:232px" %)Избыточная задержка сигнала|(% style="width:1151px" %)Свойство обозначающее, что процесс может получить сигнал (и продолжить обработку) позже чем мог бы (при использовании других подходов).
6	6	|(% style="width:232px" %)Stream триггер|(% style="width:1151px" %)Триггер, отслеживающий состояние процесса (выполняется он или нет).
7	7	Реализуется через отправку TriggerEvent в момент остановки выполнения процесса (делается автоматически если зарегистрирован).
8		-Пробуждает процесс (передает новый сигнал), только после того как процесс перешел в состояние ожидания.
9		-|(% style="width:232px" %)Wakeup condition|(% style="width:1151px" %)(((
10		-Модуль wakeup condition проверяет условие наличия новых сигналов перед остановкой процесса.
	8	+|(% style="width:232px" %)Wakeup condition|(% style="width:1151px" %)Модуль wakeup condition проверяет условие наличия новых сигналов перед остановкой процесса.
11	11	От разработчика требуется реализация хендлера проверки условия.
12		-)))
13		-|(% style="width:232px" %)Wakeup lock (Wakeup state)|(% style="width:1151px" %)(((
14		-Модуль wakeup lock добавляет отдельную таблицу для синхронизации.
	10	+|(% style="width:232px" %)Wakeup state|(% style="width:1151px" %)(((
	11	+Модуль wakeup state добавляет отдельную таблицу для синхронизации.
15	15	Используется только в сочетании с Wakeup condition.
	13	+Решает 2 задачи:
	14	+1) Информация о выполнении процесса считывается из Wakeup state (без взятия блокировки процесса). Если процесс выполняется, то сигнал считается доставленным и никаких обновлений не требуется.
	15	+2) Синхронизация проверки условия Wakeup condition, гарантия что сигнал не будет утерян.
	16	+В конце сессии обработки процесса Wakeup state блокируется и только после этого проверяется условие наличие новых сигналов Wakeup condition, это гарантирует что ни один поступивший сигнал не будет утерян.
16	16
17		-[[Гарантированная конкурентная доставка сигнала>>doc:Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Гарантированная конкурентная доставка сигнала.WebHome]]
	18	+Такой подход позволяет минимизировать ожидание на блокировках.
18	18	)))
19	19	)))
20	20	|Типы передачи сигналов|(((
21		-| |(% style="width:662px" %)Тип|(% style="width:513px" %)Пример|Триггер|Избыточная задержка сигнала|Stream триггер|Wakeup condition|Wakeup lock
22		-|1|(% style="width:662px" %)Низкая интенсивность сигналов, низкая конкуренция за процесс.|(% style="width:513px" %)(((
	22	+| |(% style="width:662px" %)Тип|(% style="width:513px" %)Пример|Триггер|Избыточная задержка сигнала|Stream триггер|Wakeup condition|Wakeup state
	23	+|1|(% style="width:662px" %)Если внешний сигнал единичный и процесс гарантировано остановлен, то его можно подать сразу на процесс (без триггера).|(% style="width:513px" %)(((
23	23	Линейный процесс отправил запрос и ждет 1 событие ответ.
24	24	Хендлер события пробуждает процесс напрямую.
25	25	)))|-|-|-|-|-
26		-|2|(% style="width:662px" %)Высокая интенсивность сигналов, высокая конкуренция за процесс.
27		-Сигнал нужно подавать через триггер.|(% style="width:513px" %) | | | | |
	27	+|2|(% style="width:662px" %)Если внешний сигнал множественный или процесс может периодически запускаться, то сигнал нужно подавать через триггер.|(% style="width:513px" %) | | | | |
28	28	|2.1|(% style="width:662px" %)Несколько конкурирующих триггеров с cannot hold lock timeout.
29	29	Если не удалось получить блокировку процесса, то выполнение триггера откладывается на некоторый timeout.|(% style="width:513px" %) |+|+|-|-|-
30		-|2.2|(% style="width:662px" %)Один stream триггер.
31		-Высокая частота сигналов, но низкая конкуренция (условие активации триггера наличие необработанного сигнала и остановка процесса).
32		-Можно использовать без таблицы Wakeup lock.|(% style="width:513px" %)Transactional outbox. См [[Примеры>>doc:Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Примеры.WebHome]] 3.|+|-|+|+-|-
33		-|2.2.1|(% style="width:662px" %)Каскад триггеров.
34		-Подход, когда 1 stream trigger передает сигнал на процесс.
35		-А другие триггеры процесса передают сигнал не на процесс напрямую, а на stream триггер.
36		-Данный подход позволяет использовать несколько триггеров (как в варианте 2.3), но не требует wakeup lock (и может работать без wakeup condition).|(% style="width:513px" %) |+|-|+|+-|-
37		-|2.3|(% style="width:662px" %)Несколько конкурирующих триггеров.
38		-Высокая интенсивность сигналов, высокая конкуренция за процесс.
39		-Для сглаживания конкуренции используется Wakeup lock (share блокировка минимизирует блокировку и сглаживает конкуренцию).|(% style="width:513px" %) |+|-|-|+|+
40		-|3|(% style="width:662px" %)Периодическая проверка|(% style="width:513px" %)Процесс пробуждается каждые N timeout, используется только 1 timer trigger. См. [[Примеры>>doc:Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Примеры.WebHome]] 1 (блок 2).|+|+|-|-|-
	30	+|2.2|(% style="width:662px" %)Если используется один stream триггер, то можно обойтись без таблицы wakeup state entity.|(% style="width:513px" %)Transactional outbox.|+|-|+|+-|-
	31	+|2.3|(% style="width:662px" %)Несколько конкурирующих триггеров.|(% style="width:513px" %) |+|-|-|+|+
	32	+
	33	+
41	41	)))
42	42	| |
43	43