Создал отдельную тему для 21663641 .
В общем, вчера, после перезапуска базы, удалил две неиспользуемые таблицы. Сегодня утром попытался продолжить удаление и снова:

Таблицы эти без ВК и прочего - просто таблица с данными. К ней никто не обращается. В MON$STATEMENTS никаких ссылок на удаляемые таблицы нет. В IBExpert'не ничего не делал, значит, это точно не он. То есть кто блокирует - загадка.

Влад, ответьте, пожалуйста, на следующие вопросы:
1. После отключения последнего пользователя от базы, все блокировки метаданных просто уничтожаются вместе со снятием блокировки с файла базы?
2. Блокировка связана с коннектом? Я понял, что препарированный запрос живет без транзакции, а если пользователь отключается от базы, не удалив препарированный запрос?
3. Через fb_lock_print можно увидеть, кто держит блокировку таблицы?

И отдельный вопрос:
1. Так как используется счетчик, нет возможности узнать, кто конкретно поставил блокировку?
Явно известно только в каком коннекте она используется.
Чтобы узнать точнее, нужно перебрать все запросы в кеше метаданных данного коннекта.
Есть возможность сделать доработку сообщения, которая покажет, в каких коннектах используется таблица?

wadmanЧерез isql?
Через isql все работает.
Разбираюсь с SQL-монитором в IBExpert. Походу, это таки он виноватый.

P.S. Отпишусь еще попозже.

Симонов ДенисКак ты себе это представляешь, если будет 500 коннектов?
Attachments: 1, 2, 5, 10, 1001, 1004, 50112 and more (total: 500).

Спасибо за ответы.

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

hvladДа. Но т.к. эта утилита не рассчитана на конечного пользователя, то способ не очевиден и требует некоторых знаний устройства ЛМ.
Хотя и весьма прост :)
А можете вкратце описать? Я самостоятельно попробую покопать в этом направлении.

Симонов Дениспо мне так лучше сделать специальную таблицу мониторинга в которой будет содержаться все объекты метаданных на которые наложены блокировки. Ну и детализировать это другими таблицами (связанные коннекты, запросы, транзакции). Не знаю насколько это сложно реализовать, но было бы круто
Это да, вообще идеальный вариант. Отпадет сразу куча проблем и вопросов.

Симонов ДенисВлад вроде ясно сказал, что такого быть не может. Умирающий коннект, убивает так же все объекты, которыми он владеет. Иначе это уже бага в ядре
Ты не понял. Коннект, умирая, смотрит, есть ли у него блокировки. И если есть, пишет в лог. По такому принципу работает обнаружение утечек памяти (в EurekaLog и FastMM) - при выходе из приложения проверяется, есть ли неосвобожденные участки памяти.

Симонов Денис,

В руководстве по FB 3.0 про MON$TRANSACTIONS.MON$STATE написано:
Состояние транзакции:
• 0 — бездействующая;
• 1 — активная.

Как понимать слово "бездействующая"?

Влад, вопроизвел lock conflict в т.ч. и на isql.

Что требуется: 2 подключения. Можно IBExpert, можно isql.
1. Коннект №1. Создаем таблицу:


Делаем выборку:


Транзакцию не коммиттим.

2. Подключаемся к базе Коннект №2.
Удаляем таблицу


Получаем исключение:
Откатываем транзакцию.

3. Мы знаем, что это выполняющийся запрос в Коннекте №1 нам мешает удалить таблицу.
Подтверждаем транзакцию у Коннекта №1. Теперь блокировок нет и мы спокойно можем удалить таблицу.

4. В коннекте №2 снова запускаем удаление таблицы:


Но сервер не может это сделать:

Откатываем транзакцию.

5. Пробуем удалить таблицу в коннекте №1. То же самое. Всё, таблицу никто не использует, но удалить ее не можем.

6. Достаточно любому коннекту отключиться и таблицу можно удалить.

Симонов Дениси что? Это ожидаемое поведение для no wait транзакции.
Очевидно что ни isql, ни IBE unprepare не делают
Что? Какое unprepare? Про это в документации есть?