softwarerПодозреваю, с точки зрения производительности (которая, вроде как, очень важна) стоит убрать некую программу и делать все на сервере БД. Для случайно выбранной задачи это обеспечит такой прирост быстродействия, что не будет нужно ни тредов, ни чего либо еще. А иначе следующей задачей поставите кластер, чтобы распихать треды по разным машинам.
Ну, не всегда время обработки ограничивается только ресурсами системы... Впрочем, раз тредстартер это не упомянул, у него не такой случай.)

Вот кстати, подобную задачу можно было бы довольно красиво решить, если бы в условии выборки можно было бы задать что-то вроде WHERE ... IS NOT LOCKED. Достаточно было бы из каждого потока делать запросы вроде SELECT ... WHERE ... IS NOT LOCKED LIMIT 1 FOR UPDATE (или, если хотите SELECT TOP 1 ... WHERE ... IS NOT LOCKED FOR UPDATE), конечно, при наличии row level locking. Однако я не знаю, есть ли возможность в какой-либо СУБД задать такое условие... Кто-нибудь в курсе о такой возможности?)

А можно пример?

Спасибо

Ну, зависит от... Если сама обработка достаточно продолжительная, относительно обработки запроса СУБД -- почему бы и нет? Зато наверняка, особенно, если обработка идёт не многопоточным процессом, а несколькими процессами. Все процессы при этом абсолютно одинаковы, обработка распараллеливается на произольное количество обработчиков, если по каким-то причинам один из обработчиков помер в процессе, залоченная им запись освобождается по таймауту, и обрабатывается любым другим, не образуя гребёнку пропущеных записей и не требуя особой обработки подобной ситуации.

softwarer
DocAlесли по каким-то причинам один из обработчиков помер в процессе,
Хм. А может программировать так, чтобы этого не случалось?

М... Если имеется в виду, "так, чтобы обработчики не помирали", это не всегда зависит от разработчика, если же "чтобы помирание как-то обрабатывалось", создавать также некого пастуха, то не всегда это и надо.
softwarer
DocAlи обрабатывается любым другим, не образуя гребёнку пропущеных записей и не требуя особой обработки подобной ситуации.
И без этого будет все то же самое. Естественный результат обработки - простановка флага "обработано"; запись без этого флага подхватится любым процессом, который вновь потянется за следующей порцией данных.

В то же время такой процесс естественно подразумевает и коммиты по каждому чиху; для Oracle такой режим не слишком удачен в смысле эффективности, да и, подозреваю, для любого другого сервера тоже (коммит означает одно из двух - либо необходимость гарантированно сбросить на диск все данные транзакции, то есть журнал, либо возможность потерять данные закоммиченной транзакции, что совершенно недопустимо).
Ммм... А оракл не позволяет выставлять стратегию сохранения логов транзакции для отдельной сессии?

Да, забыл добавить, в предложенном вами в этой ветке методе, то есть, при распределении записей по остатку от деления нацело, то в нём никто не подхватит. Хотя, конечно, как вы и указали, это не единственный возможный вариант.

softwarer DocAlМ... Если имеется в виду, "так, чтобы обработчики не помирали", это не всегда зависит от разработчика,
Хм. Если полагать, что "не использовать левых библиотек" итп зависит от разработчика, то скорее таки всегда.

На практике - я делал такое серверное приложение, и начальство скомандовало использовать для слежения за ним ранее написанного "пастуха". В итоге от этой мысли отказались, потому что "пастух" периодически умирал, в то время как мое приложение - работало :)

DocAlМмм... А оракл не позволяет выставлять стратегию сохранения логов транзакции для отдельной сессии?
Позволяет. Насколько я понимаю, это один из шагов в сторону облегчения работы криво написанных приложений, наподобие того же параметра cursor_sharing. Но это не значит, что этот режим стоит использовать.
Ну, мы с вами просто работаем в разных областях, со своей спецификой, у вас, видимо, все данные для обработки уже имеются на сервере, хранятся в упорядоченном виде в СУБД, и конечно тут скорость обработки зависит практически исключительно от системых ресурсов, выделенных на это, а надёжность этой обработки полностью в руках разработчика. Но так бывает не всегда. С другой же стороны, мне не очень понятно, почему, если категорически недопустимо потерять результат обработки каждой записи, не дёргать-таки сервер коммитом, после этой самой обработки, а если это не столь принципиально -- то не заставлять сервер сбрасывать на диск лог транзакций "от каждого чиха". Да, можно, конечно, просто дёргать его не каждый чих, а каждый десятый, или там, каждый сотый чих, но это ведь симптоматическое лечение, всегда есть шанс потерять результаты обработки 9 (99) записей, да и почему бы серверу самому не разобраться, когда ему дёргаться?