Существует задача (БД Oracle), где множество получателей обращаются к одной очереди и выбирают из нее данные, допустим "талоны" на действие, где каждый должен получить собственный набор.
Но, т.к. подключения осуществляются параллельно то возможно одновременное получение одинаковых "талонов" двумя получателями.

Что следует использовать, для решения проблемы? Oracle Advanced Queuing? Или что-то еще или как-то "на-коленке"?

Здравствуйте, Plague, Вы писали:

Да, "стандартно рекомендованный" подход заключается в использовании AQ. В ряде случаев можно и нужно использовать и "наколеночное" решение на основе SELECT WHERE ROWNUM < 2 FOR UPDATE NOWAIT SKIP LOCKED — так, чтобы каждый соискатель получал очередную запись.

> Существует задача (БД Oracle), где множество получателей обращаются к
> одной очереди и выбирают из нее данные, допустим "талоны" на действие,
> где каждый должен получить собственный набор.
> Но, т.к. подключения осуществляются параллельно то возможно
> одновременное получение одинаковых "талонов" двумя получателями.

SELECT FOR UPDATE + NOWAIT

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Plague, Вы писали:

S>Да, "стандартно рекомендованный" подход заключается в использовании AQ. В ряде случаев можно и нужно использовать и "наколеночное" решение на основе SELECT WHERE ROWNUM < 2 FOR UPDATE NOWAIT SKIP LOCKED — так, чтобы каждый соискатель получал очередную запись.

"NOWAIT SKIP LOCKED" — с 11.2 больше не работает, т.е. либо "NOWAIT", либо "SKIP LOCKED"
NOWAIT — по-сути выдает сразу, что ресурс заблокирован, тут все понятно.

Более того, попробовал с SKIP LOCKED — первый запрос выдает данные, второй параллельно второй уже выдает 0 записей, т.к. запись с ROWNUM = 1 заблокирована, т.е. выдает записи с ROWNUM 2,3,4 и т.д.

Подобная конструкция не работает, почему-то теряет ROWID О_о, выдавая ORA-01446: cannot select ROWID, заменив ROWNUM чем-нить — без ошибок, но не то, что нужно.

select t.*
  from (select t.rowid, t.*, rownum rnum
          from QUEUE_TABLE t
         where downloaded = 0) t
where t.rnum < 2
   for UPDATE SKIP LOCKED

Здравствуйте, Plague, Вы писали:

P>Здравствуйте, Softwarer, Вы писали:

S>>Здравствуйте, Plague, Вы писали:

S>>Да, "стандартно рекомендованный" подход заключается в использовании AQ. В ряде случаев можно и нужно использовать и "наколеночное" решение на основе SELECT WHERE ROWNUM < 2 FOR UPDATE NOWAIT SKIP LOCKED — так, чтобы каждый соискатель получал очередную запись.

P>"NOWAIT SKIP LOCKED" — с 11.2 больше не работает, т.е. либо "NOWAIT", либо "SKIP LOCKED"

Видимо надо SKIP LOCKED выбирая только первую строку, ROWNUM, как всегда, не надежен ))

Здравствуйте, Plague, Вы писали:

P>Что следует использовать, для решения проблемы? Oracle Advanced Queuing? Или что-то еще или как-то "на-коленке"?

Можно и так, и так. Но на счёт AQ я бы сказал, что это -- несвойственная для Oracle задача, её лучше делать вообще
отдельно, не в БД и не с помощью СУБД.
Есть AtciveMQ, RabbitMQ, Hornet, ZeroMQ и дофига прочих разных.