Удобный запрос для блокировки строк.

[RXL]

Долго изучал мануалы MySQL, пытаясь понять, можно ли сократить следующее выражение:

Код:

SELECT * FROM tab WHERE ... FOR UPDATE;

Смысл в том, что мне не нужны данные запроса.
Попробовал такой вот изврат и... получилось:

Код:

SELECT MIN(1) FROM tab WHERE ... FOR UPDATE;

Интересно, как с этим обстоят дела у других СУБД?

[x77]

не совсем понятно, что ты хочешь селектить. вернее, совсем непонятно. в том же майэскюэль

Код:

 UPDATE t1 SET column2 = (SELECT MAX(column1) FROM t1); 

отработает на ура.

[RXL]

Игор, цель — не выборка данных, а блокировка строк. Чтобы выполнить над ними серию запросов и апдейтов и чтобы никто их не изменил, пока я не завершу транзакцию.

[x77]

ходят упорные слухи, что в 4-м мускуле появилась поддержка транзакцй? (О.о)

сделай поле LockCount, и все апдейты по условию

Код:

where LockCount = 0

. перед обновлением поле увеличиваем, после апдейта - уменьшаем.

[x77]

з.ы. кстати, Ром, чем тебя стандартные блокировки не устраивают? lock tables READ|WRITE - штатная ф-ия.

[RXL]

Транзакции в MySQL появились вместе с форматом базы InnoDB. Не помню точно - примерно в версии 4.0.?-maxdb - это давно было. Дефолтным все равно остается MyISAM, но если надо - можно использовать любой другой.

Игор, одно дело блокировка всей таблицы, а другое дело - набора строк. Разные транзакции могут не мешая друг другу блокировать разные строки.

Собственно, это к теме никаким боком не относится. Вопрос один - как СУБД, которые поддерживают блокировки уровня строк, отнесутся к моему сокращению.

[RXL]

Oracle 10g: ORA-01786: FOR UPDATE of this query expression is not allowed

Где бы еще проверить?..

[Алексей++]

в interbase (вернее FB1.5) тоже проканало ))

[RXL]

Это хорошо. Я уж думал было, что MySQL одинок в своем извращении.

Кстати, в попытках вернуться к классической форме — без групповых функций — запробовал поместить в курсор в процедуре. Работает!

Код:

DECLARE curs CURSOR FOR
  SELECT id FROM tab WHERE id IN (...) FOR UPDATE;

OPEN curs;
CLOSE curs;

[Sla]

запробовал поместить в курсор в процедуре. Работает!

Убейте меня об стену...
Звонок юзеров (вернее продвинутых технологов).
- Слава! Висит! Все!

туда, сюда, нахожу процесс, грохаю не разбираясь.
через 15 минут - опять звонок.
Туда, сюда, грохаю.
15 минут. Задача поднималась из job'а
Тут я не выдерживаю. Лезу в job
и...

DECLARE curs CURSOR FOR
  SELECT id FROM tab WHERE id IN (...) FOR UPDATE;

OPEN curs;
..............

CLOSE curs;

там лочилась вся! таблица. Я после этого с разработчиком, вернее - цей, месяца два не раговаривал,а еще вернее она со мной, потому как услышала от меня поток ненормативной лексики в ее адрес .

так шо аккуратней с таким курсором

[RXL]

Слав, дык транзакции надо завершать - иначе обязательно вылезет.

Вся таблица могла залочится в том случае, если id не входит в ключ или его левую часть, т.к. блокируются на самом деле не строки, а записи в индексе.

[Sla]

все было намного сложнее и не понятнее, как с ее стороны, так и с моей.

С т.зрения - ее селект фор апдейт  в данной ситауции логичен, ... ну и куча объяснений почему.

С моей стороны - у меня на сервере  1гиг памяти озу + 10гиг свободного на диске, под swap было отдано 3 гига.
Результат курсора очень большой, его нужно где-то "хранить". И началось... А к оперативным таблицам шло постоянное обращение, начинались конфликты. А это job, он если завершился с ошибкой, то начинает долбать. по крайней мере такие были сетингсы у этого джоба.

А задача была простая.
Каждые 15 мин выборка из оперативных таблиц, и  update в другую схему.
 

[RXL]

Слав, смотри, если я сделаю так:

Код:

DECLARE curs CURSOR FOR
  SELECT NULL FROM tab WHERE id IN (...) FOR UPDATE;

Т.е. набор данных минимальный. Даже если залочу миллион строк, то памяти съест совсем немного.

[Sla]

RXL, та я твой курсор показал только скопировав, потому что вспомнил, а разговор к тому что к такой конструкции select for update нужно подходить думаючи о последствиях