Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9   вперед  Ctrl      все
 Re: Firebird + fbExpress lock conflict  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896
ъъъъъ
Вот и растут зарплаты дельфистов...
жаль, руководство об этом не знает...
23 ноя 21, 18:42    [22399880]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1454
Гаджимурадов Рустам

Ты же сам говоришь - некому, все разбежались.

Ну в случае если рак на горе свистнет вдруг заплатят и/или перепоручат.))
23 ноя 21, 18:49    [22399882]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2668
Гаджимурадов Рустам,

а модераторам доплачивают за сложность и напряжённость?
Или только за секретность?
24 ноя 21, 05:28    [22400019]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 21053
ъъъъъ,

У каждого модератора есть крипто-кошелёк, куда складываются все проклятия на его голову.
24 ноя 21, 09:20    [22400047]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Старый плюшевый мишка
Да-да-да. И даже собственно исходники программы - это на самом деле набор ноликов и единичек.

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

Dimitry Sibiryakov

GJ
Ну, будет 2К. Почему вы упорно отвергаете вариант просмотреть 2 десятка ХП,
которые выполняются в блокирующей транзакции?

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

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

Vlad F
Поговорить вот любит, это да. Сказывается многолетний опыт модерирования Королевства Delphi.))

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

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

eSem
GJ

* * *
Еще один маленький вопрос по dbExpress. Понимаю, что не по теме, так как здесь специалисты по Firebird, но все же... вдруг кто-то знает... Мы можем открыть запрос не стартуя явно транзакцию. При этом в Firebird транзакция создается автоматом, но в приложении TSQLConnection.InTransaction остается false. Собственно, а какова дальнейшая судьба этой транзакции? Она будет болтаться до закрытия соединения?
Вопрос не критичный (любопытство), поэтому специально рыть не нужно. Просто на тот случай, если кто-то уже сталкивался и знает.

Да, такая транзакция будет висеть до закрытия соединения с БД.
Чем она закончится можно посмотреть в таблице MON$TRANSACTIONS колонки MON$AUTO_COMMIT и MON$AUTO_UNDO. Встроенный драйвер dbExpress D7 для всех транзакции выставляет значения (0, 1), соотвественно.

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

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

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

Vlad F
WildSery

Не был в "королевстве дельфи", неужели там всё так плохо.

Все это к тому что у него достаточно длительный опыт Delphi-разработки, но академического плана, не DB-aware направления.
А сейчас чел попал, оставшись, как понимаю, практически один в антигуманном DBX-окружении, - все кто это в свое время (наш)кодил разбежались.

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

* * *
Что еще... В принципе, все полезное, что я мог получить в этой теме, я получил. Может, есть еще какие хитрости, которые были бы мне полезны, но, скорее всего, больше ничего здесь не выплывет. Если вы считает, что я такой злобный флудер, загадивший весь sql.ru, могу и свалить. А могу и дальше отвечать на здешние сообщения. Судя по количеству участников в теме и "содержательности" сообщений, некоторые любят пофлудить куда больше, чем я.
24 ноя 21, 12:33    [22400139]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

а шо, "королевство" таки совсем издохло?
(интересуюсь)

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 12:43    [22400142]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
GJ
А совет заменить все UPDATE на INSERT -- это вообще хит!

для вас может и хит, а вообще это вполне нормальное решение. Например:
https://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept
24 ноя 21, 12:53    [22400149]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Мимопроходящий

а шо, "королевство" таки совсем издохло?
(интересуюсь)

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

kdv
GJ
А совет заменить все UPDATE на INSERT -- это вообще хит!

для вас может и хит, а вообще это вполне нормальное решение. Например:
https://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept

Я неверно расставил акценты. Имелось в виду, что такой вариант возможен, но как один из. Мне же его подавали как единственный возможный вариант обезопасить себя от блокировок.
24 ноя 21, 13:05    [22400153]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896
GJ
Мимопроходящий

а шо, "королевство" таки совсем издохло?
(интересуюсь)

Форум вопросов (Круглый стол) функционирует, но самих вопросов очень мало, так как, собственно, по Delphi вопросов мало (прошел пик популярности), а это была самая сильная сторона Королевства. Так что остался "мемориал": накопленный за пару десятков лет материал в виде публикаций и обсуждений.
печально.
здешний форум Delphi ожидает та же участь - число активных участников форума скукожилось до неприличного числа.
да и те что есть, такие же "винтажные газогенераторы" как и все мы тут.
молодь вся на шарпе.
24 ноя 21, 13:12    [22400157]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Мне же его подавали как единственный возможный вариант обезопасить себя от блокировок.
Так ведь так и есть. При insert блокировки невозможны, при update - возможны.
Делаешь логику на insert - и не паришься вообще о блокировках.
24 ноя 21, 13:21    [22400160]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
YuRock
При insert блокировки невозможны, при update - возможны.
Хотя есть один кейс, когда и при update невозможны. И это, кстати, похоже на твой случай.

Добавляем шапку докуманта.
Затем добавляем позиции и апдейтим шапку для каждой позиции.
Всё это - в одной транзакции, до коммита. Тогда другие транзакции эту запись просто не увидят, и потому ничего и не сделают, и блокировки не будет.

Но, конечно, такая логика - ужасна.
А если еще и где-то коммит вставить случайно, а еще и используя при этом компоненты с возможностью автостарта/автокоммита транзакций, как у тебя - будут совсем вилы.
24 ноя 21, 13:36    [22400172]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805

GJ
Почему вы уверены, что нельзя посмотреть в mon$statements запросы, относящиеся к
конкретной транзакции?

Потому что я знаю как эта таблица работает.

GJ
На тестах все работало.

"Дуракам везёт." (с)

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 13:56    [22400184]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
YuRock
GJ
Мне же его подавали как единственный возможный вариант обезопасить себя от блокировок.
Так ведь так и есть. При insert блокировки невозможны, при update - возможны.
Делаешь логику на insert - и не паришься вообще о блокировках.

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

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

Dimitry Sibiryakov
GJ
Почему вы уверены, что нельзя посмотреть в mon$statements запросы, относящиеся к
конкретной транзакции?

Потому что я знаю как эта таблица работает.

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

Dimitry Sibiryakov
GJ
На тестах все работало.

"Дуракам везёт." (с)

Будем надеяться, что я и дальше останусь дураком ;)

Сообщение было отредактировано: 24 ноя 21, 14:59
24 ноя 21, 14:59    [22400221]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805

GJ
Вот и я хотел бы это узнать.

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

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 15:18    [22400228]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov

GJ
Вот и я хотел бы это узнать.

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

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

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

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

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

В чем может быть подвох? Туда попадут (могут попасть) не все запросы, выполненные в рамках транзакции 1?
24 ноя 21, 15:59    [22400250]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
GJ,

ты забыл о транзакции 3 из-за которой lock conflict и получился
24 ноя 21, 16:02    [22400252]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Симонов Денис
GJ,

ты забыл о транзакции 3 из-за которой lock conflict и получился


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

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

Ни один не подходит? Почему? Мы можем недополучить какие-то данные?
24 ноя 21, 16:15    [22400261]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805

GJ
Вы сообщили мне информацию о том, что знаете как это работает, и о том, что это
описано в хелпе. Но мне интересно не то, и не то.

А мне не интересно что тебе интересно. Я хочу просто заставить тебя наконец-то
прочитать уже эту документацию.

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

Да, именно так. Потому что в момент "выбираем из mon$statements" интересные
запросы уже не выполняются. В лучшем случае они там есть, но не привязаны к
транзакции, в худшем - их уже нет, поскольку они перестали быть prepared (или
даже никогда не были).

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 16:20    [22400267]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896
GJ
Ни один не подходит? Почему? Мы можем недополучить какие-то данные?
"снимок" состояния выполняется один раз, при первом обращении к MON$-таблицам.
все последующие обращения (в этом же контексте) изменения картины не покажут.
24 ноя 21, 16:21    [22400268]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov

А мне не интересно что тебе интересно.

Понял, до свидания.
24 ноя 21, 16:26    [22400273]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
GJ,

именно. Запрос который делал UPDATE ты получишь, но его безо всякого мониторинга можно получить, просто подняв стек при обработке исключения можно получить точнее место в программе. А вот кто с ним конфликтовал не факт, ибо сюрприз транзакция 3, уже может быть завершена к тому времени, а уж тем более запросы которые привели к конфликту.
24 ноя 21, 16:27    [22400275]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Мимопроходящий
GJ
Ни один не подходит? Почему? Мы можем недополучить какие-то данные?
"снимок" состояния выполняется один раз, при первом обращении к MON$-таблицам.
все последующие обращения (в этом же контексте) изменения картины не покажут.

Запускаю 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
Или что вы понимали под контекстом?

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

именно. Запрос который делал UPDATE ты получишь, но его безо всякого мониторинга можно получить, просто подняв стек при обработке исключения можно получить точнее место в программе. А вот кто с ним конфликтовал не факт, ибо сюрприз транзакция 3, уже может быть завершена к тому времени, а уж тем более запросы которые привели к конфликту.

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

Стартует транзакция 1.
В рамках транзакции 1 выполняются какие-то запросы, в том числе и тот, который меняет таблицу и послужит причиной блокировки.
Транзакция 1 НЕ завершена, когда стартует транзакция 2.
Транзакция 1 НЕ завершена, когда в рамках транзакции 2 выбираем из mon$statements все по attachment_id.
Транзакция 1 НЕ завершена, когда транзакции 2 выполнятся запрос UPDATE, на котором иногда возникает блокировка.
Если получаем lock conflict, то сбрасываем донные, полученные из mon$statements в лог.
24 ноя 21, 16:49    [22400290]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805

GJ
Транзакция 1 НЕ завершена, когда транзакции 2 выполнятся запрос UPDATE, на
котором иногда возникает блокировка.

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

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 17:01    [22400296]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11555
GJ
Запускаю IBExpert, открываю два окна
1. В окне 1 выполняю запрос SELECT
2. В окне 2 выполняю запрос
select * from mon$statements where mon$attachment_id = NNN
В результатах вижу запрос из окна 1
Выполни несколько разных запросов в окне 1 на шаге 1.
24 ноя 21, 17:17    [22400304]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov

GJ
Транзакция 1 НЕ завершена, когда транзакции 2 выполнятся запрос UPDATE, на
котором иногда возникает блокировка.

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


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

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

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

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

hvlad
GJ
Запускаю IBExpert, открываю два окна
1. В окне 1 выполняю запрос SELECT
2. В окне 2 выполняю запрос
select * from mon$statements where mon$attachment_id = NNN
В результатах вижу запрос из окна 1
Выполни несколько разных запросов в окне 1 на шаге 1.

Уп-с... заинтриговал...
Ладно, будем надеяться на лучшее. Если не прокатит, и моя "ловушка" окажется пуста, буду логировать все старты и завершения транзакций.
24 ноя 21, 17:31    [22400315]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить