Моделирую следующее поведение на своем тестовом приложении (Delphi, пробовал на компонентах IBX и UIB):

1. Стартую транзакцию (в моем случае Read Committed, Rec Version, Read Only, но похоже не важно)
2. Открываю любой простой SELECT запрос в клиентском приложении


3. Этот запрос появляется в MON$STATEMENTS
4. Затем я закрываю запрос и делаю Free для запроса в клиентском приложении


5. По исходникам компонент в режиме отладки видно, что вызывается isc_dsql_free_statement с параметром DSQL_DROP, что на мой взгляд должно приводить к полному закрытию запроса и освобождению всех связанных с ним ресурсов.
6. Но при этом запрос остается висеть в MON$STATEMENTS в состоянии MON$STATE = 0
7. Запрос пропадет из MON$STATEMENTS только после закрытия транзакции

Хочу понять, насколько это правильное поведение и с чем оно связано?
Например, при наличии долгой Read транзакции и периодического создания, выполнения, освобождения запросов в ней, они останутся висеть в MON$STATEMENTS, хотя по факту полностью закрыты на клиенте.

И в связи с этим еще один вопрос: тратятся ли в данной ситуации ресурсы сервера на такие запросы, в каком объеме и насколько критично с точки зрения производительности?

Версия Firebird и клиентских библиотек 2.5.4.26856 Windows x64 (SuperServer).

dimitrВладимир Архипов,

не должно такого быть. Что-то где-то делается не так.

Хочу уточнить, если допустить, что компоненты доступа (проверил несколько, поведение одинаковое) делают все правильно с точки зрения вызова функций клиентской библиотеки Firebird, то такое поведение неправильное и быть такого не должно, так?

Если все-таки это какая-то специфика поведения Firebird, то, на мой взгляд, это неудобно с точки зрения анализа таблиц мониторинга. Я всегда предполагал, что IDLE запросы из MON$STATEMENTS - это незакрытые запросы, по которым нет никакой активности, а теперь получается, что полностью закрытые на клиенте запросы продолжают висеть MON$STATEMENTS с тем же статусом MON$STATE = 0 до закрытия транзакции?

Коваленко ДмитрийДа это, наверное, lazy-mode.
Что такое lazy-mode?

dimitrВладимир Архипов,

для начала надо бы рассказать, в какой именно транзакции запрашивается MON$STATEMENTS. Ибо о его снапшотности тут уже высказались неоднократно.

во-вторых, после IBQuery1.Free() запрос умрет на сервере и исчезнет из MON$STATEMENTS (если ее правильно обновить). Но оный free может уйти с клиента серверу не мгновенно, а в момент следующего обращения. На этот (обычно короткий) период запрос будет висеть на сервере и быть виден в MON$STATEMENTS.

Таблицу MON$STATEMENTS я смотрю в отдельном коннекте в отдельной транзакции. Для каждого просмотра MON$STATEMENTS я делаю рестарт транзакции, про "снапшотность MON$STATEMENTS" я знаю.

dimitrНо оный free может уйти с клиента серверу не мгновенно, а в момент следующего обращения.
Вот теперь я понял, не заметил сразу, спасибо. Это наверно было сделано для оптимизации сетевого взаимодействия между клиентом и сервером. Просто получается, например, что в случае долгой Read транзакции мы можем видеть висящий запрос с MON$STATE = 0, но на самом деле он может быть уже закрыт, просто после него пока ничего не делали и транзакцию тоже не закрывали. Но в целом это наверно уже мелочи...

Вопрос закрыт, всем спасибо.