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


приведенный набор хинтов не только блокирует записи, но и делает их невыдимыми для точно таких же запросов, вызываемых из других транзакций - они получают непересекающиееся наборы данных.
Попробовал аналог в ASE 15.7 - ничего не получается. В том числе и для каждого хинта по отдельности.



Что это? Неправильный запрос или драйвер не справился? Используется jtds-1.3.1

White Owl,

сценарий такой: есть буферная таблица, в которую попадают данные, и эти данные надо дальше передать, в другие системы. Для этого некий робот периодически делает запрос к данной таблице, примерно такой, как наверху. Робот работает в XA транзакции, в результате обеспечивается атомарное взаимодействие с другими системами. В простейшем случае никаких хинтов не надо, но всё осложняется тем, что для устойчивости и масштабируемости одновременно работает несколько таких роботов.
Задача в том, чтобы не было конкуренции за одни и те же записи, и не было ожиданий, пока освободятся блокировки.
Приведенный набор хинтов updlock, rowlock, nowait, readpast в MSSQL решает данную задачу.

Можно конечно пойти классическим путем: берем очередную запись и помечаем на удаление


но тогда запись блокируется, и если параллельная транзакция сделала такую же выборку и попыталась также удалить эту запись, то ей придется ждать результатов текущей транзакции.
Поэтому хочется как в MSSQL - сразу выбирать непересекающиеся наборы.
Ну ладно, пусть они даже пересекаются, главное не ждать.
Поможет ли команда

?

White Owl,
я ничего этого делать не буду. Во-первых, я не разработчик БД, а интегратор. Работаю с тем, что дали на вход.
Во-вторых, это не ETL. На выходе у меня не данные, а запуск бизнес процессов. Для простоты - JMS.
И параллельность тоже не моя прихоть, а данность. Она тут в основном для отказоустойчивости и непрерывности обработки.

Вот в этих условиях надо избежать конкуренции за одни и те же записи, желательно без сериализации.

В общем, добрался до базы и проверил. Без всяких хинтов работает классический шаблон



Медленнее, чем с хинтами (в MSSQL), которые сразу возвращают непересекающиеся наборы данных, но главное без блокировок. Блокировок записей нет -> опасность дедлока отсутствует.

Увы, но речь идет о запросе с клиента. Это не курсор и не сохраненная процедура

MasterZiv,

SELECT FOR UPDATE - это первое, что я попробовал. Сервер сообщает, что такой селект может использоваться только в объявлении курсора или в теле хранимой процедуры. Возможно, есть какие-то настройки в конфигурации сервера, открывающие возможность использования этого выражения в обычном клиентском запросе, но я уже написал выше, что мне они недоступны.
Что касается классического шаблона блокировки записи, то она достигается не селектом, а удалением. Как это работает - написано в длинном комментарии выше.

MasterZiv,