|
|
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
oracle 12.1 есть таблица-очередь заявок на обслуживание вида Код: plsql 1. 2. 3. 4. в эту таблицу одни процессы добавляют строки со статусом Новая, другие процессы (демоны разбора очереди, больше одного, способ реализации - Informatica или Java) должны: - захватывать одну заявку в статусе Новая по сортировке FIFO - менять ее статус на Обработка - производить некую работу - менять статус на Завершена вопрос: как правильно работать с таблицей очереди из демонов разбора очереди - так, чтобы два и более одновременно работающих демона не смогли ухватиться за одну и ту же заявку? думаем в сторону select for update (nowait?) - есть ли опыт/пример/подводные камни? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 14:58 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Alexus12- менять ее статус на Обработкачтобы потом маяться с определением потерянных записей и обрабатывать с пропуском очередности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 15:03 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Alexus12думаем в сторону select for update (nowait?) - есть ли опыт/пример/подводные камни?skip locked ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 15:06 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Alexus12вопрос: как правильно работать с таблицей очереди из демонов разбора очереди - так, чтобы два и более одновременно работающих демона не смогли ухватиться за одну и ту же заявку? DBMS_LOCK Alexus12думаем в сторону select for update Бросьте. "Тут рыбы нет." Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 15:08 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
ElicAlexus12думаем в сторону select for update (nowait?) - есть ли опыт/пример/подводные камни?skip locked С обязательным построчным фетчем курсора унутре "демона" и фиксацией транзакции по факту обновления статуса (row-by-row). ...следует обратить внимание на prefetch, который в этой модели может попортить крови при неаккуратном обращении :) Кроме того, в табличке заданий весьма желательно помимо статуса иметь атрибуты с датой (или таймстэмпом) его (статуса) изменения, а также - неким идентификатором обработчика (должен позволять однозначно найти хост и конкретный процесс ОС) на предмет отлова "зависших" заявок и самопомерших/цинично пришибленных "демонов". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 17:10 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov"Тут рыбы нет." Есть. Но надо правильно готовить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 17:10 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousКроме того, в табличке заданий весьма желательно помимо статуса иметь атрибуты с датой (или таймстэмпом) его (статуса) изменения, а также - неким идентификатором обработчика (должен позволять однозначно найти хост и конкретный процесс ОС) на предмет отлова "зависших" заявок и самопомерших/цинично пришибленных "демонов". нафига? помер - откатится , завис - вычислится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 17:59 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
DВАнафига? помер - откатится , завис - вычислится Если обработка занимает время, то промежуточный(ные) статус(ы) "in progress" требуется для мониторинга. А при введении таких статусов требуется решать проблему нештатно отвалившихся обработчиков ("зависших" заданий). Отдельный сценарий - обработка на сервере приложений (возможно, кластеризованном) с пулом (пулами) коннектов, когда нельзя долго удерживать сессию БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 18:40 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousЕсли обработка занимает время, то промежуточный(ные) статус(ы) "in progress" требуется для мониторинга. инсерт-делит в автономке на небольшой таблице мониторинга дешевле, чем дополнительные поля и индекс на основной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 19:19 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousDВАнафига? помер - откатится , завис - вычислится Если обработка занимает время, то промежуточный(ные) статус(ы) "in progress" требуется для мониторинга. А при введении таких статусов требуется решать проблему нештатно отвалившихся обработчиков ("зависших" заданий). Отдельный сценарий - обработка на сервере приложений (возможно, кластеризованном) с пулом (пулами) коннектов, когда нельзя долго удерживать сессию БД. проблема нештатно отвалившихся обработчиков решается выборкой со skip locked не обращающей внимания на статус "in progress" ) Потому что если оно реально "in progress", то запись заблокирована обработчиком и будет пропущена, если "in progress" - наследие умершего обработчика, то возьмется снова в обработку и снова станет актуальным "in progress" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 19:34 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
DВАесли оно реально "in progress", то запись заблокирована обработчиком и будет пропущена Это хорошо в предположении, что обработка занимает меньше суток. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 20:08 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovDВАесли оно реально "in progress", то запись заблокирована обработчиком и будет пропущена Это хорошо в предположении, что обработка занимает меньше суток. то, что занимает больше суток, в очередь как правило не выносят ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 20:14 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
DВАесли оно реально "in progress", то запись заблокирована обработчиком и будет пропущенаИ пока один проверяет in progress, другие проверяльщики и обработчики полагают отсутсвие очереди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 21:17 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
[quot DВА]andrey_anonymousзапись заблокирована обработчиком 1. установка статуса предполагает фиксацию транзакции, т.е. обработчик должен будет блокировать строчку дважды, что усложняет логику и требует разрешения коллизий на втором раунде блокировки 2. не всякий обработчик может позволить себе удерживать сессию БД в процессе работы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 10:24 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
-2-инсерт-делит в автономке на небольшой таблице мониторинга дешевле, чем дополнительные поля и индекс на основной. it depends... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 10:25 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
спасибо всем ответившим! дополнения: авторС обязательным построчным фетчем курсора унутре "демона" и фиксацией транзакции по факту обновления статуса (row-by-row). предполагается, что каждый демон разбора очереди а) получает (через select for update) всего одну строку по порядку сортировки FIFO, меняет ей статус на Обработка и комитит, после чего запускает некий внешний обработчик с ИД этой заявки Затем происходит обработка, и обработчик последним своим писком делает апдейт статуса заявки на Завершена. Т.о.: - время лока строки заявки демоном - минимальное - демон не должен лочить больше одной строки за раз вижу на других форумах важное замечание: автор важное отличие для работы с курсорами - курсор с for update залочит все строки попадающие под условие курсора сразу при open, а если добавить skip locked, то только те строки будут залочены, которые были действительно считаны в fetch, что позволяет: ограничить коллличество залоченых строк, или возвращать открытый курсор как результат функции с ещё не залочеными строками. вопрос: как правильно в нашем случае отобрать и залочить всего одну строку, чтобы такого не происходило? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 12:42 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Если хорошо подумать, то условие "всего одну строку" в подобных задачах в большинстве случаев оказывается ничем не обосновано кроме "общих соображений" )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 13:50 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Alexus12меняет ей статус на Обработка и комититНе увидел ответа на вопрос о смысле бытия. Alexus12автор...курсор с for update залочит все строки попадающие под условие курсора сразу при open, а если добавить skip locked, то только те строки будут залочены, которые были действительно считаны в fetch...... чтобы такого не происходило?Не происходило блокировки строк for update при выполнении open и for update skip locked при выполнении fetch? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 14:04 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Alexus12как правильно в нашем случае отобрать и залочить всего одну строку, чтобы такого не происходило? 1. Объявляем курсор select for update skip locked 2. Парсим, выполняем (PL/SQL: open). 3. Делаем 1 (ОДИН) фетч 4. закрываем курсор, работаем с полученной строкой ...PL/SQL: можно for-loop с безусловным exit в первой же итерации Ахтунг1: никаких "rownum=1" и т.п. в запросе "skip locked" быть не должно Ахтунг2: драйвер БД может использовать различные prefetch, когда вызов fetch на стороне клиента ведет к тому, что на сервере будет вычитано (и залочено), скажем, 5 или 10 строк. Поэтому для реализации подобного механизма всякие префетчи лучше отключать (driver specific). Как-то так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 14:26 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
DВАЕсли хорошо подумать, то условие "всего одну строку" в подобных задачах в большинстве случаев оказывается ничем не обосновано кроме "общих соображений" )) Ээээ... Нат, пусть у тебя в очереди 10 заданий. И 5 обработчиков. Первый дернул for update и заблокировал все 10 заданий. Модель с удержанием сессии: Остальным не досталось (т.е. по факту не более одного активного обработчика в один момент времени). Модель с коммитом: Остальные крутят холостые циклы пока первый не зафиксирует транзакцию (ненужная сериализация и избыточный поллинг). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 14:32 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, как сделать, чтобы первый схватил 1 строку - и остальным тоже досталось по строке? демон в общем случае - процедура на pl/sql, т.е. никаких лишних прослоек между ним и базой нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 14:37 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
Alexus12andrey_anonymous, как сделать, чтобы первый схватил 1 строку - и остальным тоже досталось по строке? демон в общем случае - процедура на pl/sql, т.е. никаких лишних прослоек между ним и базой нет Чукча не читатель? 21679573 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 14:41 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousDВАЕсли хорошо подумать, то условие "всего одну строку" в подобных задачах в большинстве случаев оказывается ничем не обосновано кроме "общих соображений" )) Ээээ... Нат, пусть у тебя в очереди 10 заданий. И 5 обработчиков. Первый дернул for update и заблокировал все 10 заданий. Модель с удержанием сессии: Остальным не досталось (т.е. по факту не более одного активного обработчика в один момент времени). Модель с коммитом: Остальные крутят холостые циклы пока первый не зафиксирует транзакцию (ненужная сериализация и избыточный поллинг). Почему холостые? У меня очередь, которая постоянно пополняется и количество обработчиков подогнанное к числу минимально необходимых, для того, что бы количество записей в этой очереди было нулевым. Первый дернул все что есть на момент его запроса из очереди и в обработку, второй и остальные то, что добавилось позже, если кому-то не достается и это происходит часто, значит у меня обработчиков сильно дохрена и их нужно сократить. А вот за обработку по одной записи да еще в порядке очереди - поубивала бы ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 15:12 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
DВАПервый дернул все что есть на момент его запроса из очереди и в обработкуНе часто можно свести обработку к bulk операциям. А в oltp-системах это часто и вредно, так как увеличивается время удержания блокировки на ключевые данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 15:21 |
|
||
|
самописная таблица-очередь и select for update
|
|||
|---|---|---|---|
|
#18+
DВА... А вот за обработку ... да еще в порядке очереди - поубивала бы ) Ничего, что могут быть такие задачи, события в которых обязаны обрабатываться именно в порядке их текущего расположения, с приоритетом, назначенным им в очереди? А вот параллелятся ли они вообще, и, если да, то как именно - это уже другой вопрос. И, имхо, не так много шансов, что skip locked проявится в ответе на него. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2018, 15:24 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39704548&tid=1883422]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
201ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 560ms |

| 0 / 0 |
