CyberMaxhvladЗачем nowait ? Не надо nowait
Так если в wait, то сервер зависает.
Я тогда что-то не понял. При работе в FB 2.5 я модификацию метаданных всегда делал в nowait-транзакции. FB при коммите сразу же выдавал сообщение об ошибке, если что-то пошло не так. Здесь же из-за особенностей FB3 пришлось это делать в wait-транзакции и получилось, что в случае lock conflict - зависание.
Как тогда правильно?Указывать конечное время ожидания
Перечитай 21662490 и 21662579


CyberMaxhvladЧто такое повторный запуск ? В какой тр-ции ?
В IBExpert делаю выполнение этого же запроса (DROP TABLE IMP_TABLE) в этой же транзакции после неудачного предыдущего выполнения.Ну так таблица уже помечена как удаляемая (в кеше метаданных текущего коннекта). После роллбека пометка снимется.

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

попробуй провести эти эксперименты в isql, ибо IBExpert иногда наступает сам себе на...+1

CyberMaxМеня этот LC очень смущает. Ведь это означает, что есть какая-то конкурирующая транзакция. И я хочу выяснить, какая.Не обязательно тр-ция. Кеш метаданных удерживает блокировки объектов. Для этого не нужны тр-ции.

Счётчик использования объекта метаданных (таблицы, индекса и т.п.) инкрементируется в двух случаях
- при препарировании запроса
- при выполнении запроса в тр-ции

Соответственно декремент происходит при
- уничтожении препарированного запроса
- завершении тр-ции

Итого, блокировку объекта может удерживать не только тр-ция, но и факт существования препарированного запроса (который так или иначе использует объект)

CyberMax1. Так как используется счетчик, нет возможности узнать, кто конкретно поставил блокировку?Явно известно только в каком коннекте она используется.
Чтобы узнать точнее, нужно перебрать все запросы в кеше метаданных данного коннекта.

CyberMax2. В 3.0 кэш метаданных - раздельный. Каким образом увеличивается счетчик блокировок моего коннекта, если объект используется в другом коннекте?Никаким не увеличивается.

CyberMax3. Если транзакция завершается без уничтожения препарированного запроса - он уничтожится?Конечно нет. Запросом владеет тот, кто его создал - пользователь.
Системные запросы пока не обсуждаем.

CyberMax4. Блокировка действует в рамках транзакции. Или может быть такое, что активных транзакций нет, а блокировка - есть?Блокировка метаданных никак не привязана к области действия тр-ции.

Ещё раз. Есть объекты метаданных. Они загружаются в кеш метаданных по мере необходимости.

С каждым таким объектом связан existence lock (блокировка существования).
При загрузке объекта в кеш и до начала его использования берётся existence lock в shared (SH) режиме.
Каждый "пользователь" объекта метаданных инкрементирует счётчик использования объекта.
Пока счётчик не нулевой, existence lock не может быть отпущен.

Есть два вида таких пользователей - препарированный запрос и активная тр-ция.
Для того, чтобы удалить объект, нужно получить existence lock в exclusive (EX) режиме.
Чтобы его получить, все кеши должны отпустить свои SH блокировки.
Это невозможно, пока соотв. счётчики использования не нулевые.

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

Симонов ДенисА вот возник такой вопрос, а можно ли сделать так чтобы при перекомпиляции объекта метаданных, связанные с ним препарированные запросы становились инвалидными и перепрепарировались как только эти запросы потребуются? Я не в смысле ближайшего будущего, а вообще теоретически.Теоритически - можно всё, что не противоречит теории :)

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

- Что делать с запросом, который сейчас выполняется ?
- Что делать с запросом, который выполнился, но тр-ция ещё не завершена ?
Не думаю, что разные результаты выполнения одного запроса в одной тр-ции будут именно тем, что ожидает прикладной программист

И т.д. - уверен, что это только верхушка айсберга

Arioch,

ты абсолютно не в теме. Писательский зуд ?

Dimitry Sibiryakov2) Когда эта удалённая запись становится мусором, сборщик мусора пробует получить локНе нужно сборщик мусора превращать в сферического мета-коня. Это не будет работать.

PS казалось бы - при чём тут инвалидация препарированных запросов...
PPS ты хочешь приделать версионность к метаданным, это нормально, но зачем скрещивать ужа с ежом - я не понимаю

Dimitry Sibiryakov,

сюрпризов пока что не обнаружено. wait тр-ция ведёт себя так, как ей положено.

Ну а мои светлые мысли пока что останутся со мною.
Их и так есть чем занять.