И к чему это глубокомысленное утверждение?
Если вы в предложении "В памяти ведётся лог вызываемых модулей и их закрытия" сходу поймете, что речь идет о паскалевском UNIT, то вы точно телепат :)


Потому что такого варианта нет. Если бы был - Вы бы уже давно им воспользовались.

Ну почему нет? Почему вы уверены, что нельзя посмотреть в mon$statements запросы, относящиеся к конкретной транзакции? На тестах все работало. Сейчас жду, когда ошибка снова возникнет у заказчика, мне пришлют лог, и буду анализировать.


С моего предыдущего сообщения в теме добавилось три десятка новых. Сколько из них содержательных, посчитай сам. Так что это большой вопрос, кто больше любит поговорить :)
Про связь между модерацией и болтливостью -- это нечто новое. Я про такое не слышал.
Кстати, на Королевстве Delphi для флудосообщений предусмотрена специальная пометка "Комментарий к предыдущим ответам", чтобы те, кому важна только суть вопроса, отвлекались на чтение флуда.

И еще раз подчеркну, что мои сообщения -- это ответы на сообщения других (причем, далеко не на все), сам я ничего не набрасываю. Так что если я люблю поболтать, то остальные -- вообще балаболки.


Спасибо. У меня получилось так же, но думал, что я что-то сделал не так и хотел проводить дополнительные исследования.


Вы ничего не перепутали? Это мне как раз советуют (зачем-то) лопатить тонны ХП, а я как раз и думаю, как уменьшить это количество до разумных пределов.


Ну ты хоть не набрасывай дополнительно, знаешь же, о чем идет речь.
Где-то в коде на Delphi при определенных условиях возникает ситуация, когда выполнение кода проскакивает мимо завершения транзакции, а потом стартует новая, вносятся изменения и получаем конфликт. Из информации у меня только лог работы, а этого недостаточно, чтобы быстро найти место и причину. Опыт работы с базами данных у меня только чуть меньше, чем опыт программирования на Pascal-Delphi, так что я и с (ш)кодингом разберусь, и с остальным. К тебе и сюда я обратился за помощью в нюансах работы Firebird и взаимодействия с dbExpress. Получил несколько полезных ответов (кстати, только сейчас узнал про Trace в IBExpert :D) и много-много флуда. А совет заменить все UPDATE на INSERT -- это вообще хит! До того я думал, что круче категорического запрета на GOTO ничего быть не может. Я заблуждался :D

* * *
Что еще... В принципе, все полезное, что я мог получить в этой теме, я получил. Может, есть еще какие хитрости, которые были бы мне полезны, но, скорее всего, больше ничего здесь не выплывет. Если вы считает, что я такой злобный флудер, загадивший весь sql.ru, могу и свалить. А могу и дальше отвечать на здешние сообщения. Судя по количеству участников в теме и "содержательности" сообщений, некоторые любят пофлудить куда больше, чем я.

Форум вопросов (Круглый стол) функционирует, но самих вопросов очень мало, так как, собственно, по Delphi вопросов мало (прошел пик популярности), а это была самая сильная сторона Королевства. Так что остался "мемориал": накопленный за пару десятков лет материал в виде публикаций и обсуждений.


для вас может и хит, а вообще это вполне нормальное решение. Например:
https://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept
Я неверно расставил акценты. Имелось в виду, что такой вариант возможен, но как один из. Мне же его подавали как единственный возможный вариант обезопасить себя от блокировок.

Так оно и есть, если клиент работает непосредственно с таблицами. А если подготовить специальные ХП, то сбоя в работе пользователь получит сообщение, что данный документ правится другим пользователем, и внесение в него изменений невозможно. А если разработать специальное клиентское приложение, то там пользователь даже откратыь документ на редактирование не сможет, получит то самое сообщение, что документ пока занят.

Вот я и говорю, что вариантов много. Вы рассматриваете самый простой: как можно избежать блокировок, если не заморачиваться обеспечением нормальной работы в многопользовательском режиме.


Потому что я знаю как эта таблица работает.
Вот и я хотел бы это узнать. А мне вместо этого говорят "делай так, не делай так" :)


"Дуракам везёт." (с)
Будем надеяться, что я и дальше останусь дураком ;)

Внезапно, но она работает так, как написано в README.monitoring_tables. Хотя
понятие "active statement" может быть и не совсем интуитивным, но таки да, это
запросы, выполняющиеся непосредственно в момент построения снимка.

Диалог с вами напоминает мне один диалог из "Летучей мыши":
"
-- Баронесса, а где вы жили в Париже?
-- В этом году?
-- Да.
-- Ну... там же, где и в прошлом."

Так и у нас. Сравните:
-- Это не будет работать.
-- Почему?
-- Потому что я знаю, как это работает.
-- Как?
-- Так же, как и написано в хелпе.

Вы сообщили мне информацию о том, что знаете как это работает, и о том, что это описано в хелпе. Но мне интересно не то, и не то. Мне интересно, почему это не даст (может не дать) нужный мне результат.

Стартуем транзакцию 1.
Последовательно выполняем какие-то запросы, транзакцию не завершаем.
Стартуем транзакцию 2.
Выбираем из mon$statements все по attachment_id.

В чем может быть подвох? Туда попадут (могут попасть) не все запросы, выполненные в рамках транзакции 1?

Вариант 1.
Стартуем транзакцию 1.
Последовательно выполняем какие-то запросы, транзакцию не завершаем.
Стартуем транзакцию 2.
Выполняем запрос UPDATE
Если получаем lock conflict, то выбираем из mon$statements все по attachment_id.

Вариант 2
Стартуем транзакцию 1.
Последовательно выполняем какие-то запросы, транзакцию не завершаем.
Стартуем транзакцию 2.
Выбираем из mon$statements все по attachment_id.
Выполняем запрос UPDATE
Если получаем lock conflict, то сбрасываем донные, полученные из mon$statements в лог.

Ни один не подходит? Почему? Мы можем недополучить какие-то данные?

Понял, до свидания.

Запускаю IBExpert, открываю два окна
1. В окне 1 выполняю запрос SELECT
2. В окне 2 выполняю запрос
select * from mon$statements where mon$attachment_id = NNN
В результатах вижу запрос из окна 1
3. Окно 1 commit, Окно 2 commit
4. В окне 2 выполняю запрос
select * from mon$statements where mon$attachment_id = NNN
В результатах НЕ вижу запроса из окна 1
5. Окно 2 commit
6. В окне 1 выполняю другой запрос SELECT
7. В окне 2 выполняю запрос
select * from mon$statements where mon$attachment_id = NNN
В результатах вижу новый запрос из окна 1
Или что вы понимали под контекстом?


Давайте еще раз. Обе транзакции -- и блокирующая, и блокируемая -- выполняются в рамках моего приложения в рамках одного коннекта.

Стартует транзакция 1.
В рамках транзакции 1 выполняются какие-то запросы, в том числе и тот, который меняет таблицу и послужит причиной блокировки.
Транзакция 1 НЕ завершена, когда стартует транзакция 2.
Транзакция 1 НЕ завершена, когда в рамках транзакции 2 выбираем из mon$statements все по attachment_id.
Транзакция 1 НЕ завершена, когда транзакции 2 выполнятся запрос UPDATE, на котором иногда возникает блокировка.
Если получаем lock conflict, то сбрасываем донные, полученные из mon$statements в лог.

Вот это с чего ты взял? Она вполне уже может быть завершена. Для конфликта ей
достаточно выполнить UPDATE в любой момент, включая момент ПЕРЕД стартом
транзакции 2, но завершиться уже после старта транзакции 2.


1. Запускаем IBExpert, открываем два окна
2. В Окне 1 выполняем запрос UPDATE
3. В Окне 2 выполняем какой-нибудь посторонний запрос SELECT, чтобы начать транзакцию.
4. В Окне 1 выполняем COMMIT
5. В Окне 2 выполняем UPDATE той же записи, что была изменена запросом UPDATE из Окна 1
6. Блокировки нет.

Вывод: чтобы произошла блокировка блокирующая транзакция не должна быть завершена на момент выполнения запроса UPDATE в другой транзакции.
Вопрос о том, могут ли из mon$statements ичезать запросы до завершения транзакции, в рамках которой они выполнялись, остается открытым.

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

Если в приложении найдется выполняемый параллельно код, в котором вносятся изменения в БД, тогда у меня будет геморрой. Но он тогда будет по-любому, а не только из-за этой блокировки.


Уп-с... заинтриговал...
Ладно, будем надеяться на лучшее. Если не прокатит, и моя "ловушка" окажется пуста, буду логировать все старты и завершения транзакций.