Добрый день.

Существует необходимость организовать сабж в приложении, работающем с БД на MySQL.
Т.е., нужна возможность логической блокировки отдельных записей в разных таблицах.
Все таблицы на InnoDB.

Зачем?
Когда пользователь пытается открыть документ, который редактируется другим пользователем, программа не должна тупо ждать таймаута, а выдать (практически без задержки) пользователю осмысленное сообщение типа "Документ редактируется таким то пользователем. Вы можете продолжить открытие данного документа в режиме просмотра или вернуться в реестр документов."

Стандартный механизм блокировок MySQL не подходит из-за невозможности определения факта блокировки нужной записи.

На десктопных БД это делается или через общие файлы-семафоры в каталоге БД или через мютексы/семафоры средствами самой ОС.

Делать что-то подобное через флаговые записи в специальной таблице бессмысленно - может быть много ложных блокировок из-за некорректного завершения приложения/вырубания питания и пр.

Более менее подходит механизм GET_LOCK(lock_name,timeout), но он, к сожалению, позволяет одному коннекту иметь активной только одну блокировку - при попытке повторного вызова GET_LOCK для другого lock_name первая блокировка сбрасывается.
Т.е., из-за этого невозможно в одном коннекте заблокировать сразу несколько объектов.

Есть ли какой другой вариант, схожий по возможностям с GET_LOCK, но без вышеописанного ограничения?

Спасибо!

ScareCrowавторn MySQL 5.7.5, GET_LOCK() was reimplemented using the metadata locking (MDL) subsystem and its capabilities were extended. Multiple simultaneous locks can be acquired and GET_LOCK() does not release any existing locks. It is even possible for a given session to acquire multiple locks for the same name. Other sessions cannot acquire a lock with that name until the acquiring session releases all its locks for the name. О-о-о! А слона то я и не заметил!
Совсем не обратил внимание, что смотрел справку по 5.6 а на сервере то стоит уже 5.7.19!
Спасибо!!!

miksoftOlegROAДелать что-то подобное через флаговые записи в специальной таблице бессмысленно - может быть много ложных блокировок из-за некорректного завершения приложения/вырубания питания и пр.Нет, не бессмысленно. По крайней мере, если вместо простого флага писать время момента блокировки и идентификатор сессии, в которой эту блокировку сделали.
Тогда можно и соответствующее сообщение выдать, и блокировку снять, если исходная сессия померла.Время блокировки ни о чем не скажет - пользователь может открыть документ на редактирование и спокойно уйти обедать или вообще уйти домой (и такое бывало!).
Ид сессии тоже бесполезная информация - как приложение с правами обычного юзверя (стандартный набор из select-insert-update-delete-execute-show_view только для заданной БД) сможет узнать статус заданной сессии?
А держать фоновый процесс-чистильщик на сервере - не та задача, чтобы наворачивать вокруг нее лишнюю инфраструктуру.

miksoftOlegROAВремя блокировки ни о чем не скажет - пользователь может открыть документ на редактирование и спокойно уйти обедать или вообще уйти домой (и такое бывало!).Да пожалуйста. Через некоторое время сессия будет грохнута и блокировка снята.

OlegROAИд сессии тоже бесполезная информация - как приложение с правами обычного юзверя (стандартный набор из select-insert-update-delete-execute-show_view только для заданной БД) сможет узнать статус заданной сессии?Масса вариантов - дораздать права, использовать логины вместо ID, вообще свой учет сессий сделать в приложении (особенно если все сидят под одним логином MySQL). Я бы сделал первое.
OlegROAА держать фоновый процесс-чистильщик на сервере - не та задача, чтобы наворачивать вокруг нее лишнюю инфраструктуру.Отдельный процесс не нужен. В СУБД есть встроенный шедулер.

В общем, вариантов реализации - масса.
И сделать это работоспособно и надежно можно вполне.Увы, слишком много лишних телодвижений и прав для данной задачи.
А вот метод с GET_LOCK все это позволяет сделать легко и без лишних приготовлений.

В общем, остановился именно на нем - спасибо всем!