Изменения документа Движок cccc1808. ProcessEngine

Сводка

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

Подробности

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

Содержимое

...	...	@@ -18,13 +18,13 @@
18	18	* Транзакции: транзакции.
19	19	* Транзакции: savepoint.
20	20	(если используются, можно обрабатывать каждый шаг отдельной транзакцией или весь процесс без savepoint изоляции ошибок между шагами).
21		-* Блокировка: updatelock.
22		-* Блокировка: updatelock skip locked.
	21	+* [[Блокировки>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.WebHome]]: updatelock.
	22	+* [[Блокировки>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.WebHome]]: updatelock skip locked.
23	23	(частично можно обойтись без него).
24		-* Блокировка: sharelock
	24	+* [[Блокировки>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.WebHome]]: sharelock
25	25	(можно обойтись без него без сильного влияния)
26		-* Уровень изоляции: работает на read committed, то что нужно блокируется руками.
27		-* Для некоторых кейсов желательно возможность выполнить upsert (insert on conflict).
	26	+* [[Уровни изоляции>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.Уровни изоляции | Isolation levels.WebHome]]: работает на read committed, то что нужно блокируется руками.
	27	+* Для некоторых кейсов желательно возможность выполнить [[Upsert>>doc:Разработка.Базы данных.SQL.Сценарии и вопросы.Insert or update\. Upsert.WebHome]] (insert on conflict).
28	28	)))
29	29	|(% style="width:150px" %)Брокер сообщений|(% style="width:1177px" %)(((
30	30	Используется для накопления и доставки TriggerEvent.
...	...	@@ -35,8 +35,8 @@
35	35	)))
36	36	)))
37	37	|(% style="width:132px" %)Особенности|(% style="width:1301px" %)(((
38		-|(% style="width:159px" %)Батчинг при выполнении.|(% style="width:1168px" %)(((
39		-Возможность использовать и комбинировать разные типы выполнения как
	38	+|(% style="width:159px" %)Пакетные транзакции (батчинг).|(% style="width:1168px" %)(((
	39	+Возможность использовать и комбинировать типы выполнения для разных типов процессов:
40	40
41	41	* (1 транзакция - 1 процесс),
42	42	* (1 транзакция - N процессов).
...	...	@@ -60,6 +60,7 @@
60	60	См. пример 2.
61	61	)))
62	62	|(% style="width:159px" %)Перехват ошибок|(% style="width:1168px" %)Перехват и обработка ошибок, если процесс выкинул exception в движок. Реализацию простого retry с задержкой (создается триггер на следующую попытку).
	63	+В случае пакетной транзакции движок не знает какой конкретно из процессов породил ошибку (если она не перехвачена вручную), то
63	63	|(% style="width:159px" %)Параллельное выполнение|(% style="width:1168px" %)Допускается запуск нескольких раннеров (на разных нодах), работающих с одной таблицей процессов для распределения нагрузки между ними.
64	64	Допускается фильтрация типов процессов между нодами (чтобы нода выполняла только определенные типы процессов, в том числе по приоритету).
65	65	Доступно для раннеров процессов и триггеров.
...	...	@@ -99,15 +99,7 @@
99	99	)))
100	100	|(% style="width:870px" %)[[image:Родительский дочерний процесс. Sequence.jpg]]
101	101	|(% style="width:870px" %)(((
102		-Возможен вариант №2, когда мы просто ставит timerTrigger на условно 1-5 минуту (насколько важна задержка) и перепроверяем условие завершения (по нагрузке на БД будет еще меньше). Из минус, что родительский процесс узнает о завершении дочерних процессов с задержкой (хотя в задержке можно использовать функцию от количества необработанных дочерних процессов, но тогда нужно считать количество).
103		-
104		-* Но тут будет join нагрузка на БД (если шаг проверки выполняется пакетно), иначе будет просто много одиночны запросов на чтение (условно раз в минуту).
105		-* Если дочерний процесс остановиться в ошибке, то родительский либо также продолжит крутиться в проверке, либо должен также пробросить ошибку в себя чтобы приостановиться.
106		-В случае с решением 1, со страхующим триггером это можно обойти через фильтрующий индекс если мы начинаем идти сразу с таблицы процессов (т.е. процессы с ошибкой сразу будут игнорироваться).
107		-* Но все равно, именно данный движек может позволить настроить 2 процесса таким образом, что 1 процесс будет исполняться (1 процесс - 1 транзакция) в параллельном режиме (пока создаются множественные дочерние процессы), 2 процесс будет исполняться в пакетном режиме (N процессов - 1 транзакция) чтобы проверять выполнение условия завершения дочерних процессов через запрос (один пакетный).
108		-
109		-плюсы: меньше пишущей нагрузки (т.к. триггер со счетчиком будет делать условно одну запись на процесс в 5-20 секунд), а тут будет одна запись в 1-5 минуту на обновление таймера.
110		-минусы: больше читающей нагрузки с join (раз 1-5 минуту нужно будет выполнить join незавершенных процессов с дочерними). У решения 1 тоже есть такая нагрузка, но на страхующем триггер (условно раз 10-30 минут).
	103	+
111	111	)))
112	112	)))
113	113	|(% style="width:32px" %)2|(% style="width:171px" %)Transaction outbox stream process.|(% style="width:1066px" %)[[image:TransactionOutbox. Sequence.jpg]]