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

Откуда:
Сообщений: 50
Нарвался на lock conflict при попытке выполнить запрос UPDATE. Начал анализировать код, но, вроде бы, нет одновременно выполняющихся транзакций. Новая стартует не раньше, чем будет выполнен COMMIT или ROLLBACK для предыдущей. Да к тому же блокировка возникает не всегда, а лишь иногда.

Сумасшедшее предположение: приложение отработало слишком быстро, а сервер FB тормознул. В результате на сервер приходит команда на старт новой транзакции, когда предыдущая еще не завершилась. Имеем две различные транзакции, что делает возможным лок конфликт. Может такое быть? Если да, то есть ли культурный способ борьбы с этим безобразием, кроме как вставить что-нибудь типа Sleep(5000) перед StartTransaction?

[+]
Опечатка в заголовке темы: конечно же речь идет о dbExpress

Сообщение было отредактировано: 18 ноя 21, 08:33
18 ноя 21, 08:29    [22397285]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ,

Если Commit/Rollback выполнился без ошибок - значит, транзакция на сервере завершилась 100%.
Хоть я и не работал с dbExpress, но так должно быть.

Еще lock может случиться, если запись удалена другой активной транзакцией, или попала в SELECT FOR UPDATE WITH LOCK.
Или вообще у тебя no_rec_version и RC, там всё может быть.

Но скорее всего - ты что-то у себя не заметил.
18 ноя 21, 08:49    [22397288]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11555
GJ,

трейс всё покажет.
18 ноя 21, 11:11    [22397338]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Тогда, наверное, вопросы по dbExpress

1. В приложении есть три TTransactionDesc, но TSQLConnection.InTransaction есть ли вообще активная транзакция. Можно ли узнать, какая именно транзакция стартовала? Можно ли узнать, что активны одновременно более одной транзакции? Если есть возможность как-то увязать их с TRANSACTION_ID в Firebird, то вообще замечательно.

2. Создается экземпляр TSQLQuery, в него загоняется запрос, выполняется и уничтожается. И все это без явного старта транзакции. Если имеется активная транзакция, то запрос выполнится в ней. А если активной транзакции нет, тогда как? Автоматически стартует новая транзакция? А когда она завершится? А если активных транзакций несколько, то в какой выполнится этот запрос? В транзакции с максимальным ID?

автор
трейс всё покажет

Если можно, чуть побольше про то, что такое "трейс" и с чем его едят. Хотя бы на уровне ключевых слов и ссылок на описание.
Пока все: чем я располагаю, это вставка в приложение различных запросов мониторинга, которые выполняются при возникновении конфликта (с записью результатов в лог): а потом жду: когда у кого-нибудь из пользователей снова возникнет проблемная ситуация.
18 ноя 21, 11:55    [22397378]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Тогда, наверное, вопросы по dbExpress
Тут этого никто не знает.

Ясно вот что:
1. Запрос не может быть выполнен без старта транзакции, следовательно, оно умеет их стартовать автоматически, как - хз;
2. Такую ситуацию можно получить, если запущено несколько программ, работающих с одной базой.
18 ноя 21, 12:07    [22397389]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

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

почему такой странный выбор компонентов доступа? Приложение должно уметь работать не только с Firebird?

Про трейс https://firebirdsql.org/file/documentation/release_notes/html/en/2_5/rnfb25-trace.html
18 ноя 21, 12:17    [22397397]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11555
GJ
автор
трейс всё покажет

Если можно, чуть побольше про то, что такое "трейс" и с чем его едят. Хотя бы на уровне ключевых слов и ссылок на описание.
Начать можно отсюда
https://firebirdsql.org/file/documentation/release_notes/html/en/2_5/rnfb25-trace.html

GJ
а потом жду: когда у кого-нибудь из пользователей снова возникнет проблемная ситуация.
Т.е. пользователей более одного. Тогда вот это вот
GJ
Новая стартует не раньше, чем будет выполнен COMMIT или ROLLBACK для предыдущей
вообще ни о чём.

Советую подумать над природой конфликтов обновления и понять, как они возникают.
18 ноя 21, 12:17    [22397398]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Вот такой код в Delphi
  qTMP.SQL.Text := SQLText; // текст UPDATE запроса
  BConnection.StartTransaction(Trans);
  qTMP.ExecSQL;
  BConnection.Commit(Trans);


Добавил для тестирования, что если возникает exception с текстотом "lock conflict on no wait transaction deadlock update conflicts with concurrent update concurrent transaction number is 1633032010", то выполняю вот такой запрос
SELECT
  a.mon$attachment_id, a.mon$remote_address, a.mon$remote_process
FROM
  mon$transactions t
  INNER JOIN mon$attachments a ON a.mon$attachment_id = t.mon$attachment_id
WHERE
  t.mon$transaction_id = 1633032010


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

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

По ссылке сейчас схожу гляну.
18 ноя 21, 12:37    [22397414]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
pastor
Member

Откуда: Калуга
Сообщений: 1313
[quot GJ#22397414]

как связаны между собой

qTMP
BConnection

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

Откуда:
Сообщений: 50
qTMP и BConnection определены в DataModule. Значение qTMP.SQLConnection равно BConnection. Задается в design-time.
18 ноя 21, 13:01    [22397434]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11555
GJ
то выполняю вот такой запрос
Его нужно выполнять в отдельной тр-ции.
И нет гарантии, что он успеет поймать тр-цию конкурента.
18 ноя 21, 13:15    [22397450]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
У меня он выполнялся после ROLLBACK транзакции с неудавшимся запросом UPDATE (вызов вставил в раздел EXCEPTION защищенного блога. Из сообщения об ошибке, кстати, и id транзакции-конкурента получил. Запрос выполнился, приложение и адрес в лог попали. Приложение мое. Поэтому и говорю так уверенно.

Сейчас рассматриваю вариант перед выполнением запроса UPDATE проверять количество транзакций в mon$trancactions по моему аттачменту. Больше ничего в голову не приходит.
18 ноя 21, 13:24    [22397457]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Из личного опыта или из общих соображений может кто-нибудь подсказать, что здесь сделать, чтобы избежать конфликта либо выявить причину го возникновения?
Причина - обновление записи двумя активными транзакциями.
Способ избежать - не допускать такого.
18 ноя 21, 13:25    [22397459]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
YuRock
Причина - обновление записи двумя активными транзакциями.
Способ избежать - не допускать такого.

-- Ватсон, это был математик.
-- Почему вы твак решили, Холмс?!
-- Ватсон, это же элементарно! Он подумал прежде, чем ответить. Его ответ абсолютно правильный. Его ответ совершенно бесполезный.
:)

Про причину мне сказал сервер Firebird (только на инглише). А то, что для избегания неприятных последствий, нужно устранить причину -- очевидно.

Мне же интересно, что делать дальше. Ошибка не систематическая. Возникает достаточно редко. Так что даже не знаю, как мне поможет упомянутая выше трассировка. Я же не могу сидеть на всех компьютерах заказчика месяц в ожидании, когда возникнет ошибка. По сути, у меня есть только мое приложение и его лог-файл. Соответственно, мне нужно либо сделать более безопасный код (как-то проверять наличие другой транзакции перед запуском апдейта, либо сбрасывать в лог какую-то дополнительную информацию, которая позволит мне определить, что же это за транзакция осталась болтаться, и почему она осталась болтаться.
18 ноя 21, 13:41    [22397469]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
GJ
Сейчас рассматриваю вариант перед выполнением запроса UPDATE проверять количество транзакций в mon$trancactions по моему аттачменту.


Не надо пользоваться MON$ таблицами для не административных задач, иначе ваше приложение очень быстро встанет раком. Это раз.
А два, для не администраторов БД MON$ таблицы видят только данные о своих соединениях
18 ноя 21, 13:44    [22397471]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11555
GJ,


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

PS за 9 лет так и не научились ничему ?
https://www.sql.ru/forum/965872/
18 ноя 21, 13:55    [22397481]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Поскольку в моем случае я вижу проблемную транзакцию, значит тут все в порядке.
А чтобы приложение не встало раком, можно обращаться к таблицам мониторинга только для одного конкретного запроса UPDATE. А он выполняется не так уж и часто.

И я бы рад бы, но.... Есть альтернативы? Повторяю, ошибка не систематическая, возникает редко. Анализировать код на 100 тыс. строк (который дорабатывали 10 программистов на протяжении 15 лет) в поисках возможных причин возникновения такой ситуации -- это нереально. Вот и ищу способ как выкрутиться.
18 ноя 21, 13:58    [22397487]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Мне же интересно, что делать дальше. Ошибка не систематическая.

Тебе известен запрос на котором она возникает. Тебе известна таблица, которую
этот запрос обновляет. Осталось только включить мозг и понять ЗАЧЕМ он эту
таблицу обновляет и ПОЧЕМУ этот запрос посылает больше одного пользователя.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 50
hvlad
GJ,
Конфликты обновления в конкурентной среде - это норма. Их можно свести к минимуму грамотным проектированием и аккуратной реализацией,
но полностью избавиться - вряд ли. Поэтому нужно быть к ним готовым и уметь корректно обрабатывать.
И, конечно, нужно понимать их причину.

PS за 9 лет так и не научились ничему ?
https://www.sql.ru/forum/965872/

Опять общие слова, что лучше быть богатым и здоровым, чем бедным и больным.
Я и обращаюсь с просьбой, чтобы с высоты собственного опыта подсказали мне, как именно мне поступить, чтобы локализовать причину или сделать код более безопасным.

А про 9 лет... По моему, можно только порадоваться, что в чужих приложениях, которые я поддерживаю, проблемы, с которыми я не могу справиться, возникают раз в 9 лет. В моих собственных приложениях у меня не возникает проблем, с которыми приходилось бы обращаться на форум.
18 ноя 21, 14:06    [22397491]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
как именно мне поступить, чтобы локализовать причину

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

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 11555
GJ
Опять общие слова, что лучше быть богатым и здоровым, чем бедным и больным.
Имеющий уши - услышит. Ты хочешь, чтобы тебе пальцем место в коде показали ? Легко - ошибка в 17-ой строке (ц)

GJ
Я и обращаюсь с просьбой, чтобы с высоты собственного опыта подсказали мне, как именно мне поступить, чтобы локализовать причину или сделать код более безопасным.
Уже сказали - трейс (аудит) чтобы найти причину, плюс обработка конфликтов в коде.
Не нравится ? Ну давай тогда стань "богатым и здоровым" ничего не делая. Нас научишь потом.

GJ
А про 9 лет... По моему, можно только порадоваться
Не возражаю - можно и порадоваться. Вот только эти самые грабли уже обсуждали 9 лет назад и рецепт был тот же. Удивительно ?
18 ноя 21, 14:56    [22397526]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
GJ,

дарю:
http://www.ibase.ru/how_to_track_deadlocks/
18 ноя 21, 15:20    [22397541]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Странно. Я, вроде, описал ситуацию. Трассировка не прокатывает, потому что ошибка не систематическая и возникает редко. Аудит, скорее всего, тоже не получится: не допустит заказчик до своих серверов. Ситуацию я вам обрисовал: и как код на Delphi выглядит, и сообщение об ошибке, и как я определил, что блокирующая транзакция в моем же приложении. Представьте, что задача по поиску этой проблемы вам выдал ваш начальник. Что будете делать? Расказывать ему о том, что такое блокировки, почему они возникают, и что нужно в коде аккуратно обрабатывать конфликты? Пока был только один содержательный совет: проанализировать триггеры.

Если в указанных мной условиях (возможны только модификация приложения и запись в лог-файл) нет нормального способа отыскать причину, то так и скажите, что такого способа нет, анализируй свои километры кода в поисках пропущенного завершения транзакции. Или более честный ответ "я такого способа не знаю", хоть это и бьет по самолюбию. Тогда я не буду здесь сидеть, а буду что-то изобретать... или даже анализировать километры кода. Пойду вставлять запросы к таблицам мониторинга запросы к mon$transactions и mon$statements, может там что-то нарою, что поможет выявить причину ошибки.

kdv
GJ,

дарю:
http://www.ibase.ru/how_to_track_deadlocks/

Спасибо. Все просто и понятно. Для данной проблемы мне это не поможет, но когда потребуется, буду знать, где посмотреть.
18 ноя 21, 16:55    [22397603]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Представьте, что задача по поиску этой проблемы вам выдал ваш начальник. Что
будете делать?

Любое сообщение об ошибке в моём приложении идентифицирует её источник с
точностью до вызова API. Анализировать и искать уже ничего не надо, вся
необходимая информация есть в сообщении об ошибке. Осталось только пойти и
понять где я облажался.

Если приложение чужое, то первым и единственным вопросом будет "при каком
действии возникает ошибка?" Дальше просто идёшь в код и смотришь какие запросы
посылает это действие.

Posted via ActualForum NNTP Server 1.5

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

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

Если приложение чужое, то первым и единственным вопросом будет "при каком
действии возникает ошибка?" Дальше просто идёшь в код и смотришь какие запросы
посылает это действие.

Ошибка возникает при попытке выполнить запрос UPDATE. Я даже знаю строку, в которой это произошло. И даже знаю причину, почему это произошло. Есть большой и ветвистый код на Delphi с большим количеством подпрограмм, который постоянно что-то вычисляет, определяет, меняет... и все это записывает в таблицу либо посредством запросов UPDATE, либо -- SELECT FROM STORED_PROC. Вроде как все эти изменения вносятся в явно стартующих транзакциях, которые сразу же (ну, или почти сразу) завершаются. Где и почему оказалась незавершенная транзакция, я понять не могу. Поэтому даже подумал было сначала, что COMMIT на сервере может выполняться асинхронно, то есть мы команду COMMIT послали и продолжили выполнение кода, а сервер из-за нагрузки тормознул и не успел сразу эту транзакцию завершить. Но мне сказали, что так не бывает. Значит где-то как-то возникло условие, при котором выполнение программы прошло по такому пути, что обошло завершение транзакции. И мне это надо найти. Вот и пытаюсь каким-то образом угадать, где именно. Хотя бы узнать, какой именно запрос изменил запись, а транзакция осталась незавершенной. Как вариант, определить перед проблемным UPDATE, что транзакция уже имеется, и не стартовать новую, а выполнить в существующей. Но тут надо аккуратно все проанализировать, чтобы не напороться на какие-нибудь другие грабли.

Возможен вариант промежуточный: если на момент выполнения запроса UPDATE есть активная транзакция, сбросить в лог список всех запросов, которые в этой транзакции выполнялись. Все будет проще искать, чем рыть десятки тысяч строк плохо структурированного кода.
18 ноя 21, 17:19    [22397619]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Значит где-то как-то возникло условие, при котором выполнение программы прошло
по такому пути, что обошло завершение транзакции.

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

Posted via ActualForum NNTP Server 1.5

18 ноя 21, 17:41    [22397633]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
GJ
Как вариант, определить перед проблемным UPDATE, что транзакция уже имеется, и не стартовать новую, а выполнить в существующей. Но тут надо аккуратно все проанализировать, чтобы не напороться на какие-нибудь другие грабли.


Я даже скажу на какие. По какой-то причине стартовавший эту транзакцию модуль решит её откатить. И откатит вместе с изменениями в модуле, содержащем "проблемный" апдейт, который будет искренне уверен, что он свою задачу выполнил. Или модуль, содержащий "проблемный" апдейт закоммитит или отроллбачит транзакцию вместе с изменениями вызвавшего модуля или даже цепочки модулей. После чего "проблемными" станут запросы-коммиты-роллбаки в этой цепочке. Я правильно понимаю что dbExpress - это архитектурно что-то вроде BDE? Тогда от проблемы без рытья кода не уйти. В этой архитектуре использование одной глобальной транзакции разными модулями - это принцип, и модуль в первых строках должен определять активна транзакция или нет. Если активна - не коммитить и не роллбачить результат, пусть вызывающий решает. А если нет - стартовать и и завершать самостоятельно. Ибо один и тот же модуль может быть активирован разными путями-цепочками вызывающих с разной логикой. И вырубить опцию автостарт-автокоммит топором, во избежание. В других архитектурах тоже бывает потребность в таких фокусах, но здесь это принцип.
18 ноя 21, 17:47    [22397637]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

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

GJ
Значит где-то как-то возникло условие, при котором выполнение программы прошло
по такому пути, что обошло завершение транзакции.

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


Он бьёт себя пяткой в грудь что конфликтующие транзакции в стартованы одном экземпляре приложения. Но ты прав, ибо - никому нельзя верить, никому! Даже себе! Ведь хотел же только пукнуть...
18 ноя 21, 17:50    [22397641]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

GJ
Значит где-то как-то возникло условие, при котором выполнение программы прошло
по такому пути, что обошло завершение транзакции.

Не обязательно. Просто два пользователя одновременно нажали одну и ту же кнопку.
Твой план искать незавершённую транзакцию в данном случае бесполезен и только
тратит зря время.


В сообщении 22397414 я написал, что я проделал и почему сделал вывод, что транзакция именно в моем приложении. Пока не будет доказано обратное, считаю за аксиому, что изменения, послужившие причиной блокировки, сделаны в моем приложении (как вариант, в функции из dll, вызванной из моего приложения.

Dimitry Sibiryakov

Надо сделать так чтобы этот конкретный известный тебе запрос
перестал вызывать конфликты обновления. То есть либо его устранить совсем, либо
превратить в INSERT.

Давайте я немного расскажу про выполняемый код. Это все -- проведение документа. В процессе проведения выполняются всякие содержательные проверки, расчеты и т.п. На каждом этапе что-то изменяется в таблице: пересчитывается сумма, обновляется дата, меняются флажки, обозначающие какое-то изменение состояния и т.п. Цепочка действий может быть ветвистой, некоторые этапы могу выглядеть по-разному, некоторые -- вообще отсутствовать, но в любом случае -- это последовательность изменений. И каждое из них, по логике, выполняется в короткой транзакции, которая явно стартует и явно завершается. Если на каком-то этапе ХП вернула ошибку, то есть этап выполнился некорректно, соответствующая транзакция откатывается и на этом дальнейшее проведение прекращается. Тот UPDATE, на котором я ловлю конфликт, всего лишь выставляет битовый признак, означающий что документ распечатан. Я не могу заменить UPDATE на INSERT: мне надо в конкретной записи в конкретном поле значение поменять. Если я выполню этот UPDATE в рамках предыдущей транзакции, а она откатится, то ничего страшного: если бы она завершилась по ROLLBACK вовремя, то мой запрос UPDATE вообще не выполнялся бы.

Как-то так.
18 ноя 21, 18:11    [22397656]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Тот UPDATE, на котором я ловлю конфликт, всего лишь выставляет битовый признак,
означающий что документ распечатан. Я не могу заменить UPDATE на INSERT: мне
надо в конкретной записи в конкретном поле значение поменять.

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

Повторять так для каждой операции, которая наткнётся на конфликт. Другого пути -
нет.

Posted via ActualForum NNTP Server 1.5

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

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

GJ
Тот UPDATE, на котором я ловлю конфликт, всего лишь выставляет битовый признак,
означающий что документ распечатан. Я не могу заменить UPDATE на INSERT: мне
надо в конкретной записи в конкретном поле значение поменять.

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

Повторять так для каждой операции, которая наткнётся на конфликт. Другого пути -
нет.

Вот здесь у меня непонятки.
Допустим, я найду место, куда можно добавить информацию, что документ распечатан.
Допустим даже, что я найду в своем приложении все места, где используется поле из этой таблицы, и заменю на вызов записи из другой таблицы.
Но мое приложение -- это часть системы. И мне никто не позволит изменять все систему только потому, что в одном приложении где-то допустили ляп и в одном случае из десяти тысяч возникает lock coflict при апдейте. Так что это годится как временная мера, но не как окончательное решение. Устранять же проблему придется по-любому. И нормальным способом.
18 ноя 21, 18:38    [22397670]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
И нормальным способом.

Это и есть нормальный способ. Костыль для системы, которую ты не можешь поменять
всю сразу:
1. Переименовать таблицу и убрать из неё поле, вызывающее конфликт.
2. Добавить таблицу истории операций.
3. Создать view с именем старой таблицы, выбирающий из новой таблицы и таблицы
истории недостающие поля.
4. Создать триггера на этот view, которые анализируют изменения и либо изменяют
новую таблицу, либо добавляют записи в таблицу истории операций.

Posted via ActualForum NNTP Server 1.5

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

Откуда: НН
Сообщений: 8878
GJ
lock coflict при апдейте
2 юзера с апдейт запросами обязательно вызовут лок конфликт, это вопрос времени и частоты, не более.
GJ
И нормальным способом.
см. выше про замену апдейта на инсерт.
GJ
я ловлю конфликт, всего лишь выставляет битовый признак
таблица подменяется на апдейтебл вью, вьюха в своих нутрях черпает данные из основной таблицы и джойнит с последней записью таблицы статусов печати. Отряд не заметит потери бойца таблицы.
18 ноя 21, 18:52    [22397675]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8878
ДС на кнопке обошел. :)
18 ноя 21, 18:53    [22397676]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

Это и есть нормальный способ <...>

Игрушка "Сапер" была доработана, но после доработки иногда стал возникать глюк.
Разработчик не смог найти причину появления этого глюка, поэтому решил переписать kernel32.dll :)
Не знаю, как обстоит дело у Microsoft, но у нас мне никто не позволит переделывать структуру БД только потому, что в одном из приложений допущен ляп, который я не могу локализовать и устранить.

Ivan_Pisarevsky
2 юзера с апдейт запросами обязательно вызовут лок конфликт, это вопрос времени и частоты, не более.

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

* * *
Сразу расставим палочки над t
У меня есть возможность изменить код клиентского приложения, чтобы:
1. Найти, где у меня незавершенная транзакция, и завершить ее до выполнения UPDATE (оптимальный вариант).
2. Определить, что есть незавершенная программа и как-то обеспечить корректное выполнение UPDATE (принудительно закрыть предыдущую транзакцию; не стартовать новую транзакцию, а внести изменения в рамках уже имеющейся и.т.п.).
18 ноя 21, 19:24    [22397679]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
ошибка не систематическая и возникает редко
Это всегда так при неожидаемых блокировках.
18 ноя 21, 19:24    [22397680]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Сразу расставим палочки над t
У меня есть возможность изменить код клиентского приложения, чтобы:
1. Найти, где у меня незавершенная транзакция, и завершить ее до выполнения
UPDATE (оптимальный вариант).
2. Определить, что есть незавершенная программа и как-то обеспечить корректное
выполнение UPDATE (принудительно закрыть предыдущую транзакцию; не стартовать
новую транзакцию, а внести изменения в рамках уже имеющейся и.т.п.).

3. Найти все места в приложении, где при данной операции изменяется данная
таблица и свести их в один UPDATE чтобы он производился один раз за операцию.
4. Начать использовать явное управление транзакциями в данном приложении чтобы в
нём вообще осталась всего одна транзакция на всю проводку документа.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 50
YuRock
GJ
ошибка не систематическая и возникает редко
Это всегда так при неожидаемых блокировках.

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

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

Dimitry Sibiryakov

GJ
Сразу расставим палочки над t
У меня есть возможность изменить код клиентского приложения, чтобы:
1. Найти, где у меня незавершенная транзакция, и завершить ее до выполнения
UPDATE (оптимальный вариант).
2. Определить, что есть незавершенная программа и как-то обеспечить корректное
выполнение UPDATE (принудительно закрыть предыдущую транзакцию; не стартовать
новую транзакцию, а внести изменения в рамках уже имеющейся и.т.п.).

3. Найти все места в приложении, где при данной операции изменяется данная
таблица и свести их в один UPDATE чтобы он производился один раз за операцию.
4. Начать использовать явное управление транзакциями в данном приложении чтобы в
нём вообще осталась всего одна транзакция на всю проводку документа.


Дочка спрашивает у мамы:
- Как правильно пишется "флякончик" или "флюкончик"?
- Напиши "пизирек", - отвечает мама.
:)

Речь идет о кассовом чеке. Товар добавляется, удаляется, изменяется количество, меняются цены (включилась скидка при добавлении дисконтной карты), выполнили частичную оплату бонусами... как вы себе предлагаете выполнить это все в рамках одного апдейта? А если транзакция будет одна, то она может оказаться... э-э-э... очень долгой.
18 ноя 21, 19:46    [22397683]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805
GJ
Речь идет о кассовом чеке. Товар добавляется, удаляется, изменяется количество,
меняются цены (включилась скидка при добавлении дисконтной карты), выполнили
частичную оплату бонусами... как вы себе предлагаете выполнить это все в рамках
одного апдейта? А если транзакция будет одна, то она может оказаться... э-э-э...
очень долгой.

А если их будет несколько, то в базу попадёт только половина чека.

И что-то я не припомню чтобы пробитие чека в магазине занимало много времени.

PS: В любом случае причины проблемы, способы её локализации и устранения все уже названы. Дальше - работать исключительно тебе.

Сообщение было отредактировано: 18 ноя 21, 20:05
18 ноя 21, 20:01    [22397685]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
GJ
1. Найти, где у меня незавершенная транзакция, и завершить ее до выполнения UPDATE (оптимальный вариант).

вы реально управляете транзакциями в dbexpress?

12388228
18 ноя 21, 20:38    [22397689]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
YuRock
пропущено...
Это всегда так при неожидаемых блокировках.

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

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

Dimitry Sibiryakov

пропущено...

3. Найти все места в приложении, где при данной операции изменяется данная
таблица и свести их в один UPDATE чтобы он производился один раз за операцию.
4. Начать использовать явное управление транзакциями в данном приложении чтобы в
нём вообще осталась всего одна транзакция на всю проводку документа.


Дочка спрашивает у мамы:
- Как правильно пишется "флякончик" или "флюкончик"?
- Напиши "пизирек", - отвечает мама.
:)

Речь идет о кассовом чеке. Товар добавляется, удаляется, изменяется количество, меняются цены (включилась скидка при добавлении дисконтной карты), выполнили частичную оплату бонусами... как вы себе предлагаете выполнить это все в рамках одного апдейта? А если транзакция будет одна, то она может оказаться... э-э-э... очень долгой.
При сохранении кассового чека UPDATE-ы запрещены.
18 ноя 21, 22:57    [22397730]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

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

вы реально управляете транзакциями в dbexpress?

12388228


Ой, мамо, роди меня обратно... Это что, улучшенный гибрид BDE c MIDAS? Мичуринцы, нехорошая женщина... Убороли чесотку в носе ампутацией головы... Не надо на этом работать, это же ужос-ужос. Соболезную.
18 ноя 21, 23:30    [22397744]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2668
Старый плюшевый мишка
kdv

вы реально управляете транзакциями в dbexpress?

12388228


Ой, мамо, роди меня обратно... Это что, улучшенный гибрид BDE c MIDAS? Мичуринцы, нехорошая женщина... Убороли чесотку в носе ампутацией головы... Не надо на этом работать, это же ужос-ужос. Соболезную.

То ж древняя фича. Её как придумали, так и забросили сразу.
19 ноя 21, 01:37    [22397754]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 2093
GJ
-- Ватсон, это был математик.
-- Почему вы твак решили, Холмс?!
-- Ватсон, это же элементарно! Он подумал прежде, чем ответить. Его ответ абсолютно правильный. Его ответ совершенно бесполезный.
:)


GJ
Опять общие слова, что лучше быть богатым и здоровым, чем бедным и больным.


GJ
Игрушка "Сапер" была доработана, но после доработки иногда стал возникать глюк.
Разработчик не смог найти причину появления этого глюка, поэтому решил переписать kernel32.dll :)


GJ
Дочка спрашивает у мамы:
- Как правильно пишется "флякончик" или "флюкончик"?
- Напиши "пизирек", - отвечает мама.


а поциент упорот...
19 ноя 21, 06:11    [22397764]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2668
GJ,

можно операцию апдейта попробовать повторить. В обработчике исключения выполнить роллбэк (чтобы не усугублять ситуацию). Затем показать диалог с двумя кнопками "Отмена" и "Повторить попытку".
С соответствующей реакцией по каждому варианту.
Если дело действительно в случайном и редком одновременном редактировании в многопользовательском режиме - может помочь.
Ну, раз на кардинальные действия ты не желаешь идти.
19 ноя 21, 07:15    [22397766]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
Если очень хочется, можно:
1. Все без исключения апдейты этой таблицы (включая в триггерах и других процедураз) завернуть в процедуры;
2. Процедуры вида UPDATE; WHEN ... - и при исключении залогировать признак ошибки, ID записи, дату, имя пользователя, компьютера, экзешник и номер транзакции. Залогировать чз udf в файл или в автономной транзакции в базу.

Так же еще можно логировать в эту же таблицу логов ID этой записи перед UPDATE. Чтобы видно было, кто, собственно, заблокировал, и на ком упало.

Работы много, на пол дня.
19 ноя 21, 07:47    [22397770]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8878
GJ
Все остальные могут документ читать, но не изменять.
А потом окажется, что факт чтения фиксируется апдейтом поля номер 125 LAST_READ в самой таблице.
19 ноя 21, 12:04    [22397878]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov
В любом случае причины проблемы, способы её локализации и устранения все уже названы. Дальше - работать исключительно тебе.

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

YuRock
При сохранении кассового чека UPDATE-ы запрещены.

Вот этого я не понял. Это вопрос или утверждение? Почему UPDATE-ы запрещены? Как изменять значения полей записи?

Дегтярев Евгений
а поциент упорот...

На вопрос "Как выявить запрос, приводящий к блокировке (или незавершенную транзакцию), мне рекомендуют:
1. Писать программы хорошо, тогда таких проблем не будет.
2. Переписать систему "правильно"
А упорот, конечно же, "поциент"
Кстати, на другом форуме могли бы посоветовать еще и СУБД заменить на "нормальную" :)

ъъъъъ
Если дело действительно в случайном и редком одновременном редактировании в многопользовательском режиме - может помочь.

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

YuRock
Если очень хочется, можно:
1. Все без исключения апдейты этой таблицы (включая в триггерах и других процедураз) завернуть в процедуры;
2. Процедуры вида UPDATE; WHEN ... - и при исключении залогировать признак ошибки, ID записи, дату, имя пользователя, компьютера, экзешник и номер транзакции. Залогировать чз udf в файл или в автономной транзакции в базу.

Так же еще можно логировать в эту же таблицу логов ID этой записи перед UPDATE. Чтобы видно было, кто, собственно, заблокировал, и на ком упало.

Работы много, на пол дня.

А почему тогда логирование UPDATE на триггер не повесить? База большая, изменяться таблица может много откуда: запросами UPDATE, хранимыми процедурами, скриптами. Все места внесения изменений можем и не найти. Да и не позволит мне никто кардинально менять метаданные. Все изменения в метаданные должны вноситься только официальными обновлениями. Обосновать разработку такого обновления я не смогу.

Но, опять же скажу, 95% за то, что есть косячок в клиентском приложении, и его надо бы найти А для этого хотя бы определить запрос, который заблокировал запись. Или несколько запросов, которые могли это сделать. И от этого уже плясать.
Надо было задавать вопрос на форуме программистов на Delphi :)

Вот такой запрос может мне помочь?
SELECT
  *
FROM
  mon$statements
WHERE
  mon$transaction_id = NNN

где NNN -- ID транзакции, содержащей блокирующий запрос. Каков смысл поля MON$STATE, могу ли я в поисках интересующего меня запроса отфильтровывать записи по значению этого поля, так как они точно не при делах?

[+]
Ivan_Pisarevsky
GJ
Все остальные могут документ читать, но не изменять.
А потом окажется, что факт чтения фиксируется апдейтом поля номер 125 LAST_READ в самой таблице.

Вы предполагаете, а я знаю, что этого нет. Точнее, что это не планировалось, так что если есть такое, то чей-то косяк.
Но тогда мы нарывались бы на lock conflict в разных местах. А мы нарываемся в о дном и том же запросе UPDATE

Сообщение было отредактировано: 19 ноя 21, 12:12
19 ноя 21, 12:06    [22397882]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
GJ
Не знаете другого способа как определить запрос или несколько потенциальных запросов, которые могут вызвать блокировку?

ну смотри - допустим, в софте произошла ошибка по блокировке UPDATE. Ты тут же бросаешься смотреть в mon$, кто там и что. Но пока ты делал снимок mon$, конкурирующая транзакция завершилась. Всё, концов не найти.
А трассировка дедлоков по статье, которую я привел, запускается НАДОЛГО. Именно для того чтобы найти только deadlock. И тогда что-то еще можно найти.
Так что, других вариантов нет.
19 ноя 21, 12:13    [22397884]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
kdv
GJ
Не знаете другого способа как определить запрос или несколько потенциальных запросов, которые могут вызвать блокировку?

ну смотри - допустим, в софте произошла ошибка по блокировке UPDATE. Ты тут же бросаешься смотреть в mon$, кто там и что. Но пока ты делал снимок mon$, конкурирующая транзакция завершилась. Всё, концов не найти.
А трассировка дедлоков по статье, которую я привел, запускается НАДОЛГО. Именно для того чтобы найти только deadlock. И тогда что-то еще можно найти.
Так что, других вариантов нет.

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

По крайней мере, запрос к mon$transactions блокируюущую транзакцию поймал. Будем надеяться, что и запрос к mon$statements не оплошает.
Так как насчет mon$statements.mon$state? Могу ли я по значению этого поля определить те записи, которые заведомо не могут блокировать таблицу?
19 ноя 21, 12:28    [22397889]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
GJ
На вопрос "Как выявить запрос, приводящий к блокировке (или незавершенную транзакцию), мне рекомендуют:
1. Писать программы хорошо, тогда таких проблем не будет.
2. Переписать систему "правильно"
А упорот, конечно же, "поциент"
Кстати, на другом форуме могли бы посоветовать еще и СУБД заменить на "нормальную" :)


неа. Тебе прежде всего посоветовали воспользоваться инструментом трассировки или аудита. Чтобы он точно показал место проблемы. И вот когда это место будет локализовано, переписать программу так чтобы она работала правильно. Но ту продолжай упорствовать и придумывать всякую фигню с таблицами мониторинга

З.Ы. UPDATE конфликт возможен практически в любой СУБД.

И кстати какая у вас верcия FB?
19 ноя 21, 12:34    [22397896]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
GJ
Так как насчет mon$statements.mon$state? Могу ли я по значению этого поля определить те записи, которые заведомо не могут блокировать таблицу?

што???
MON$STATE (statement state)
0: idle
1: active

вообще через mon$ никакие записи "определить" нельзя.
- update выдает конфликт с номером транзакции
- по номеру транзакции ищем ее sql в mon$statements и ее коннект в mon$attachments. Смотрим на update/delete, разумеется, ну или вызов процедур, раз у вас там в селективных процедурах тоже update/delete есть.
Всё.

А "записи" (конкуренция) определяются только по параметрам конфликтных update/delete из трейса.
19 ноя 21, 12:46    [22397902]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Симонов Денис
ебе прежде всего посоветовали воспользоваться инструментом трассировки или аудита. Чтобы он точно показал место проблемы.

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


Симонов Денис
З.Ы. UPDATE конфликт возможен практически в любой СУБД.

Что не мешает фанатам одной СУБД по любому поводу советовать пользователям другой СУБД выбросить это дерьмо и поставить себе нормальную СУБД.
Впрочем, так обстоит дело с любым софтом, а не только с СУБД :)

Симонов Денис
И кстати какая у вас верcия FB?

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

Откуда: iBase.ru
Сообщений: 30261
GJ,

поправка - для трассировки никакие настройки серверов не меняются.
19 ноя 21, 12:54    [22397907]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
kdv
GJ
Так как насчет mon$statements.mon$state? Могу ли я по значению этого поля определить те записи, которые заведомо не могут блокировать таблицу?

што???
MON$STATE (statement state)
0: idle
1: active

вообще через mon$ никакие записи "определить" нельзя.
- update выдает конфликт с номером транзакции
- по номеру транзакции ищем ее sql в mon$statements и ее коннект в mon$attachments. Смотрим на update/delete, разумеется, ну или вызов процедур, раз у вас там в селективных процедурах тоже update/delete есть.
Всё.

А "записи" (конкуренция) определяются только по параметрам конфликтных update/delete из трейса.

Забыли еще про состояние 2 - stalled :)

Терминологическая путаница: замените в моем вопросе слово "записи" на "строки, возвращаемые запросом"
Итак:
Можно ли я по значению поля mon$state определить, что запрос, указанный в этой строке, не мог блокировать таблицу?

[+]
kdv
GJ,

поправка - для трассировки никакие настройки серверов не меняются.

Хм...
автор
А он может и не позволить изменять настройку серверов или запускать лишнее программное обеспечение на клиентских компьютерах


Сообщение было отредактировано: 19 ноя 21, 12:58
19 ноя 21, 12:55    [22397908]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
GJ,

нет, не можно. state тут это состояние запроса - выполняется, идет выборка записей, или еще что.
и строки или записи таблицы - это одно и то же. Как "поле" и "столбец".

Сообщение было отредактировано: 19 ноя 21, 13:01
19 ноя 21, 13:00    [22397909]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
kdv
GJ,

строки или записи таблицы - это одно и то же. Как "поле" и "столбец".

Но вы почему-то не поняли, когда я строки, возвращаемые запросом к таблице mon$statements, назвал записями ;)
19 ноя 21, 13:04    [22397912]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
А вот про локализацию что-то особо не заметил. Или вы про трассировку? Тогда я
уже объяснил, почему это неприменимо. Не знаете другого способа как определить
запрос или несколько потенциальных запросов, которые могут вызвать блокировку?

Да что ж ты такой тормоз-то?..

Тебе известно что блокирующий запрос находится в твоём приложении.
Тебе известен запрос, выбрасывающий ошибку. Отсюда известна таблица на которой
возникает конфликт.

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

Posted via ActualForum NNTP Server 1.5

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

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

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

Запросов UPDATE в приложении очень мало. В основном запросы SELECT FROM STORED_PROC. Кроме того, запросы могут быть не в самом EXE-шнике, а, например, в DLL.
19 ноя 21, 13:48    [22397939]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

Это был риторический вопрос на засыпку. Неважно где этот UPDATE, просто найди и
проанализируй их все.

Posted via ActualForum NNTP Server 1.5

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

Откуда: iBase.ru
Сообщений: 30261
GJ
Но вы почему-то не поняли, когда я строки, возвращаемые запросом к таблице mon$statements, назвал записями

да понял я. я не понял, что вы хотели извлечь из "состояния запроса", когда надо смотреть на текст запроса.
19 ноя 21, 14:10    [22397949]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ggreggory
Member

Откуда:
Сообщений: 201
GJ
В основном запросы SELECT FROM STORED_PROC.


Проверьте ваши процедуры на наличие update-ов.
19 ноя 21, 14:13    [22397951]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

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

Да заказчик-то тут вообще при чём? Трассировку и проблемную операцию запускаешь
на ЛОКАЛЬНОЙ тестовой базе. И сразу видишь сколько транзакций стартует и какие
запросы в них. После чего рихтуешь приложение пока не останется ровно одна
транзакция.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 14:17    [22397952]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

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

Но, опять же скажу, 95% за то, что есть косячок в клиентском приложении, и его надо бы найти А для этого хотя бы определить запрос, который заблокировал запись. Или несколько запросов, которые могли это сделать. И от этого уже плясать.
Надо было задавать вопрос на форуме программистов на Delphi :)

Ты погоди на Delphi, там в основном все те же рыла.))
Вот здесь 12399136 раскопано, что параметры [стартующих в приложении транзакций] wait/nowait можно указать в параметрах соединения (Sic!).
Найди, где это у тебя там, и поменяй, хотя бы временно, wait, который там скорее всего по-умолчанию, на nowait.
Должно привести к тому, что на момент получения ошибки во вторичной транзакции, первичная будет еще "жива" и, возможно, с нужным стейтментом будет присутствовать в таблицах мониторнинга.
19 ноя 21, 14:26    [22397957]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

Vlad F
Должно привести к тому, что на момент получения ошибки во вторичной транзакции,
первичная будет еще "жива" и, возможно, с нужным стейтментом будет
присутствовать в таблицах мониторнинга.

Наоборот. Вторичная транзакция зависнет, дожидаясь завершения первичной и к
моменту получения ошибки та будет гарантированно завершена. Что, впрочем, тоже
хорошо, поскольку такое зависание придаст ускорения разработчику.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 14:33    [22397963]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

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

При nowait? уверен?
19 ноя 21, 14:34    [22397964]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805
Vlad F
При nowait? уверен?

Сообщение об ошибке прочти по буквам: "Update conflict on nowait transaction".

PS: А, да, был неправ. Прочитал твоё сообщение как "заменить nowait на wait".

Сообщение было отредактировано: 19 ноя 21, 14:41
19 ноя 21, 14:36    [22397967]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

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

Возможно. Просто это плохо соотносится с изначальными заявлениями заявителя, что ничего похожего на ту "первичную" транзакцию на тот момент уже нет в таблицах мониторинга.
19 ноя 21, 14:41    [22397969]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

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

Разве? Он, помнится, ссылался на 22397414 чтобы показать, что проблемную
транзакцию таки нашёл и она оказалась в его же приложении...

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 14:53    [22397981]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

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

А где там написано, что тот его проверочный запрос что-то находит?
Впрочем, пусть еще раз выскажется сам.
19 ноя 21, 15:04    [22397989]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

Это был риторический вопрос на засыпку. Неважно где этот UPDATE, просто найди и
проанализируй их все.

В БД несколько тысяч ХП. Средний размер одной ХП, навскидку, пара сотен строк. Dependncies может не помочь, так как текст некоторых запросов собирается в run-time. Кроме того, есть еще различные dll, где тоже могут выполняться запросы. При этом каждую из найденных ХП нужно проверять, а не могла ли она выполняться в приложении в тот момент, когда возникла блокировка.
А если я ничего так и не найду, а выяснится, что у заказчика еще и дополнительные скрипты запускаются, про которые я ни сном, ни духом...
И это предлагают мне в противовес решению, сбросить в лог тексты запросов из mon$statements, которые выполнялись в блокирующей транзакции. Даже если их там окажется несколько десятков, все равно масштабы несравнимы.

Dimitry Sibiryakov

Да заказчик-то тут вообще при чём? Трассировку и проблемную операцию запускаешь
на ЛОКАЛЬНОЙ тестовой базе.

А на локальной базе ошибка не возникает. И у других заказчиков тоже не возникает. Только у одного. Спереть у него базу со всеми настройками я не могу.

Vlad F
Dimitry Sibiryakov,
А где там написано, что тот его проверочный запрос что-то находит?
Впрочем, пусть еще раз выскажется сам.

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

Сейчас поправил код приложения. Перед выполнением проблемного UPDATE-а (но после старта транзакции) сбрасываю в лог все транзакции моего соединения. А если транзакций больше, чем одна, то еще и все стейтменты моего соединения. А только потом выполняю запрос UPDATE. Если блокирующая транзакция не асинхронная, то должен все поймать.

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

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

GJ
В БД несколько тысяч ХП.

И все они вызываются из твоего приложения?..

GJ
А на локальной базе ошибка не возникает.

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

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 2668
GJ
В БД несколько тысяч ХП. Средний размер одной ХП, навскидку, пара сотен строк. Dependncies может не помочь, так как текст некоторых запросов собирается в run-time. Кроме того, есть еще различные dll, где тоже могут выполняться запросы. При этом каждую из найденных ХП нужно проверять, а не могла ли она выполняться в приложении в тот момент, когда возникла блокировка.

Ну и забей, пусть дальше глючит. Схема базы большая, а ты маленький. Да и не пацан уже, за копейки корячиться.
19 ноя 21, 18:21    [22398085]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

GJ
В БД несколько тысяч ХП.

И все они вызываются из твоего приложения?..

Нет, не все. Но есть ХП, которые вызываются из ХП, которые вызываются из моего приложения.
А есть ХП, которые вызываются из ХП, которые вызываются из ХП, которые вызываются из моего приложения.
А есть... :)

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

Dimitry Sibiryakov

GJ
А на локальной базе ошибка не возникает.

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

И что я тогда буду искать? Одновременную работу нескольких транзакций что ли?

ъъъъъ
GJ
В БД несколько тысяч ХП. Средний размер одной ХП, навскидку, пара сотен строк.
Ну и забей, пусть дальше глючит. Схема базы большая, а ты маленький. Да и не пацан уже, за копейки корячиться.

В теме были советы о том, что надо писать хорошие программы и не надо писать плохие программы.
Были советы переделать БД как надо.
Но вот совет ар жизни о том, чем и за сколько можно заниматься, пока первый :D

Сообщение было отредактировано: 19 ноя 21, 18:55
19 ноя 21, 18:54    [22398104]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1454
GJ,

А ведь он не в бровь, но в глаз, - действительно за копейки и действительно не мальчик.
И чего тебя на старости лет из бизнес-анализа в системные разработчики потянуло, - совсем что-ли в лавке никого не осталось?
19 ноя 21, 19:09    [22398113]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

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

Да вот я тоже не понимаю, почему ты собираешься просматривать тысячи ХП вместо
тех, которые реально выполняются.

GJ
И что я тогда буду искать? Одновременную работу нескольких транзакций что ли?

Да, именно это я и сказал. Кажется, даже два раза.

Posted via ActualForum NNTP Server 1.5

19 ноя 21, 19:38    [22398130]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ

YuRock
При сохранении кассового чека UPDATE-ы запрещены.

Вот этого я не понял. Это вопрос или утверждение? Почему UPDATE-ы запрещены? Как изменять значения полей записи?
Утверждение.
Потому, что они порождают блокировки и безвозвратные потери первички.
Никак не изменять. Делать только инсерты. Изменять можно потом, джобом или монопольно при пересменке.
19 ноя 21, 21:12    [22398168]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
А почему тогда логирование UPDATE на триггер не повесить?
Потому, что процедур можно было бы сделать много с разными именами (по названию места, откуда она вызывается), и логировать, в том числе, имя процедуры.
GJ
Обосновать разработку такого обновления я не смогу.
Я так и думал. Уже можно было закончить разработку, но Вы на форуме поплачете лучше еще месяцок.
19 ноя 21, 21:17    [22398170]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

Да вот я тоже не понимаю, почему ты собираешься просматривать тысячи ХП вместо
тех, которые реально выполняются.

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

GJ
И что я тогда буду искать? Одновременную работу нескольких транзакций что ли?

Да, именно это я и сказал. Кажется, даже два раза.
[/quot]
Сделал у себя на локальной БД, как ты сказал, прошел, одновременно работающих транз0акций не обнаружено. Дальше что?
И не получится как в том анекдоте... "Жаль, что все куры сдохли, а то у меня еще столько идей"

YuRock
Почему UPDATE-ы запрещены? Как изменять значения полей записи?

Потому, что они порождают блокировки и безвозвратные потери первички.
Никак не изменять. Делать только инсерты. Изменять можно потом, джобом или монопольно при пересменке.[/quot]
За четверть века работы с базами данных впервые встречаю утверждение о недопустимости применения запроса UPDATE при работе в многопользовательском режиме :)
Нет, если вы рассматриваете вариант когда в некоей абстрактной БД сотня обезьян одновременно занимается изменением данных посредством низкоуровневых запросов, то, скорее всего, вы правы.
Но я работаю с вполне конкретной системой, при проектировании которой изначально учитывалась одновременная работа многих пользователей. И нигде больше одновременно со мной никто в этой записи значения полей не меняет. Так что глупо как-то выбрасывать существующую систему и делать новую, по вашей идеологии, когда речь идет всего лишь о поиске ошибки.

YuRock
GJ
Обосновать разработку такого обновления я не смогу.
Я так и думал. Уже можно было закончить разработку, но Вы на форуме поплачете лучше еще месяцок.

Вы, похоже, совсем не читаете, что я пишу. Допустим, сделал я такой супер-мега-скрипт, который меняет кучу метаданных в БД. И что? Могу положить его на полочку и любоваться, потому что воспользоваться им не смогу. Ваш совет хорош в случае, если я -- хозяин БД. Тогда, да. Запустил IBExpert, быстренько поправил несколько сотен ХП, дописал еще несколько сотен новых... и жди, когда яблочко свалится тебе в руки.
А так... я разработку уже закончил. Философские споры -- штука бесконечная. Как только я понял, что ничего содержательного больше не будет, то сразу вставил в приложение дополнительное логирование. Теперь буду ждать, когда ошибка возникнет снова, а потм смотреть ХП, попавшие в логи, и искать место ошибки.
20 ноя 21, 15:08    [22398318]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
если вы рассматриваете вариант когда в некоей абстрактной БД сотня обезьян одновременно занимается изменением данных посредством низкоуровневых запросов, то, скорее всего, вы правы.
Я рассматриваю всего лишь реальную жизнь. В которой и репликатор может любую запись изменить в любой момент, пришедшую с центральной базы, и логика, "изначально продауманная для многопользовательской системы", иногда может содержать (или в будущем добавлять) ошибки в этой самой логике.

И вообще, что там при чеке обновлять? Сумму денег в кассе? Остаток товара? Что еще? Всё, что приходит в голову - может быть изменено вторым кассиром параллельно, ту же запись.
Потому так делать и нельзя.

GJ
А так... я разработку уже закончил.

А, ну отлично. Хорошо, что проблем нет. А на форум просто зашли, чтоб потроллить людей от скуки. Правильно!
20 ноя 21, 15:21    [22398323]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Сделал у себя на локальной БД, как ты сказал, прошел, одновременно работающих
транз0акций не обнаружено. Дальше что?

Значит надо проверять какой из высказанных выше постулатов ложен:
1) Конкурирующая транзакция находится в твоём приложении. 22397414
2) Твоё приложение всегда запущено в одном экземпляре. 22397656

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 50
YuRock
Я рассматриваю всего лишь реальную жизнь. В которой и репликатор может любую запись изменить в любой момент, пришедшую с центральной базы <...>

Не может репликатор изменить. Правки в документ могут вноситься только на одной БД. Если нужно править на другой БД, требуется передача прав. Более того, даже на одной БД если кто-то редактирует документ, остальн6ые могут только читать, но не править. Если, конечно, триггеры не отключать :)
Система изначально спроектирована так, чтобы можно было без опаски пользоваться изменением таблиц, а не загонять все изменения в некий черновик, из которого потом по ночам в монопольном режиме выполнять синхронизацию данных.

YuRock

И вообще, что там при чеке обновлять? Сумму денег в кассе? Остаток товара? Что еще? Всё, что приходит в голову - может быть изменено вторым кассиром параллельно, ту же запись.

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

YuRock

А, ну отлично. Хорошо, что проблем нет. А на форум просто зашли, чтоб потроллить людей от скуки. Правильно!

Проблема есть, но я сделал очередной шаг по выявлению ее причин. Получу дополнительную информацию, буду дальше думать.
На форум я зашел за консультацией и советом. Как только беседа пошла по кругу, я принял для себя решение и внес соответствующие изменения.
А про потроллить... тут опять как в анекдоте "Ну вы же первый начали"
Продолжаю беседу, потому что вежливый. Мне пишут, я отвечаю. Можем договориться и прекратить беседу.

Dimitry Sibiryakov

GJ
Сделал у себя на локальной БД, как ты сказал, прошел, одновременно работающих
транз0акций не обнаружено. Дальше что?

Значит надо проверять какой из высказанных выше постулатов ложен:
1) Конкурирующая транзакция находится в твоём приложении. 22397414
2) Твоё приложение всегда запущено в одном экземпляре. 22397656

Оба постулата истинны. А причина в том, что я не могу у себя на локально БД гарантировать прохождение в коде по тому же пути с теми же данными. Говорю же, что проблема возникает только у одного заказчика и очень редко.
Если бы я мог у себя воспроизвести эту проблему, я бы ее уже устранил.
20 ноя 21, 19:13    [22398397]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805
GJ
Изменяется сумма чека при добавлении товара, изменении количества
товара по строке, при изменении цены товара (например, при использовании
дисконтной карты).

Пока это проделывается только в одном документе только одной транзакцией -
сабжевой ошибки быть не может.

GJ
Говорю же, что проблема возникает только у одного заказчика и очень редко.
Если бы я мог у себя воспроизвести эту проблему, я бы ее уже устранил.

Значит таки придётся пройти всё дерево триггеров, активируемых проблемным
запросом, для выявления "какая же таблица может быть изменена за пределами
своего документа".

PS: И анализ надо проводить именно на метаданных данного клиента, ибо там могут быть незаявленные изменения.

Сообщение было отредактировано: 20 ноя 21, 19:20
20 ноя 21, 19:18    [22398403]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

Откуда:
Сообщений: 50
Dimitry Sibiryakov
GJ
Изменяется сумма чека при добавлении товара, изменении количества
товара по строке, при изменении цены товара (например, при использовании
дисконтной карты).

Пока это проделывается только в одном документе только одной транзакцией -
сабжевой ошибки быть не может.

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


Dimitry Sibiryakov

GJ
Говорю же, что проблема возникает только у одного заказчика и очень редко.
Если бы я мог у себя воспроизвести эту проблему, я бы ее уже устранил.

Значит таки придётся пройти всё дерево триггеров, активируемых проблемным
запросом, для выявления "какая же таблица может быть изменена за пределами
своего документа".

PS: И анализ надо проводить именно на метаданных данного клиента, ибо там могут быть незаявленные изменения.

Пока буду исходить из предположения, что в рамках блокирующей транзакции вносятся изменения ту же самую таблицу, которую пытается изменить запрос UPDATE. Для этого хочу получить список всех запросов, которые выполнялись в блокирующей транзакции. Если там есть такие, то буду искать, откуда они вызываются, и как могло получится, что транзакция оказалась незавершенной. Если нет, тогда уже перейдем к триггерам. Слишком уж там сложно все, потону в анализе.
20 ноя 21, 19:32    [22398408]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

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

Это ты уже проверил трассировкой. Транзакция одна.

Posted via ActualForum NNTP Server 1.5

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

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

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

Это ты уже проверил трассировкой. Транзакция одна.

Я проверил на локальной базе. Одна. А у заказчика получается две. Иногда. При каких условиях, хз.
20 ноя 21, 19:39    [22398414]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Изменяется сумма чека при добавлении товара, изменении количества товара по строке, при изменении цены товара (например, при использовании дисконтной карты). Меняется сумма оплат по чеку (например, частичная оплата банковской картой или бонусами), меняется состояние документа, меняются различные признаки.
Всё это делается перед началом процедуры пробития чека на кассе. Т.е. это - не сохранение чека.
А после этого - при сохранении - лишь перенос из одной таблицы в другую, и только INSERTы.

GJ
Продолжаю беседу, потому что вежливый. Мне пишут, я отвечаю.
О, как Вы великодушны! Спасибо, а то мы бы пропали!
20 ноя 21, 20:44    [22398435]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Пока буду исходить из предположения, что в рамках блокирующей транзакции вносятся изменения ту же самую таблицу, которую пытается изменить запрос UPDATE.
При одной тианзакции такся ошибка невозможна.
В рамках одной транзакции можно обновлять одну и ту же запись хоть 500 раз.
20 ноя 21, 20:47    [22398436]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

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

Dimitry Sibiryakov

пропущено...

Значит надо проверять какой из высказанных выше постулатов ложен:
1) Конкурирующая транзакция находится в твоём приложении. 22397414
2) Твоё приложение всегда запущено в одном экземпляре. 22397656

Оба постулата истинны. А причина в том, что я не могу у себя на локально БД гарантировать прохождение в коде по тому же пути с теми же данными. Говорю же, что проблема возникает только у одного заказчика и очень редко.
Если бы я мог у себя воспроизвести эту проблему, я бы ее уже устранил.


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

GJ

Говорю же, что проблема возникает только у одного заказчика и очень редко.


а размышления такие:
а) Предположение 1 таки ложно. И у этого заказчика есть программист, разработавший скрипт или приложение по оптимизации налогов, который изредка запускается по недосмотру в рабочее время.
б) Предположение 1 таки ложно. И некто хитрожопый, или группа таковых лиц по предварительному сговору, напоив до беспамятства админа или включив его в группу, получила доступ к базе помимо штатных приложений и уменьшает сумму в документе после выдачи клиенту бумажки, укладывая разницу в свои поганые карманцы. Обычно задним числом, но иногда торопятся. Кроме шуток, в моей практике такой случай был. Были изловлены и преданы сожжению на рыночной площади путём логирования изменений с меткой юзер-таймштамп.
в) Предположение 1 таки справедливо, но у этих кренделей есть и код Вашего приложения. И косяк в их заплатке. Но это скорее из области фантастики.
20 ноя 21, 21:35    [22398458]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
Старый плюшевый мишка,

а может и локально шпиён подключился в ибэксперте к базе, и правит там всякое!

p.s. лет 15 назад в системе на ПочтеРоссии искали барабашку, которая постоянно держит коннект к БД и активную транзакцию, причем даже рестор её не смущает - мгновенно коннектится. Ну, мы тогда были не такие ушлые, поэтому только сообщили о безобразии, а негодяя нашел кто-то на месте. Оказалось какое-то левое приложение, которое что-то там выцепляло из базы.
20 ноя 21, 23:14    [22398496]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2668
GJ
1. В приложении есть три TTransactionDesc, но TSQLConnection.InTransaction есть ли вообще активная транзакция. Можно ли узнать, какая именно транзакция стартовала? Можно ли узнать, что активны одновременно более одной транзакции? Если есть возможность как-то увязать их с TRANSACTION_ID в Firebird, то вообще замечательно.

2. Создается экземпляр TSQLQuery, в него загоняется запрос, выполняется и уничтожается. И все это без явного старта транзакции. Если имеется активная транзакция, то запрос выполнится в ней. А если активной транзакции нет, тогда как? Автоматически стартует новая транзакция? А когда она завершится? А если активных транзакций несколько, то в какой выполнится этот запрос? В транзакции с максимальным ID?


Ну, я не специалист в dbexpress...
Беглое изучение документации (help Delphi 2007) говорит, что после явного старта транзакции все последующие запросы (TSQLQuery) будут выполняться именно в контексте этой транзакции. Переключение TSQLQuery в контекст другой транзакции выполняется свойством TransactionLevel компонента (см. описание структуры TTransactionDesc, "идентификатор транзакции"). Если TransactionLevel =0, то используется контекст последней запущенной транзакции. Да, если "активной" транзакции нет, она создается.

Таки образом, поймать дедлок при такой схеме - проще некуда: ты явно стартовал транзакцию, в ее контексте сделал изменения, стартовал другую (не завершив первую транзакцию) и снова поменял ту же запись...
...
Свойство TSQLConnection.InTransaction показывает, активна ли хоть одна транзакция.
Способа определить, какая явная транзакция является "последней" в TSQLConnection - нет (я не нашел), поэтому можно тупо запоминать.
"Увязать" транзакцию с TRANSACTION_ID firebird никак нельзя. В D2007 нет исходников "драйвера".
...
Беглое знакомство с dbexpress создало впечатление, что они заточены на работу с серверами, у которых либо нет явного управления транзакциями, или одна транзакция на коннект.
...
Ты умрёшь, разгребая эту конюшню.

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

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

ъъъъъ
Беглое знакомство с dbexpress создало впечатление, что они заточены на работу с
серверами, у которых либо нет явного управления транзакциями, или одна
транзакция на коннект.

Это MS SQL. Только у него существуют вложенные транзакции.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 50
YuRock
GJ
Изменяется сумма чека при добавлении товара, изменении количества товара по строке, при изменении цены товара (например, при использовании дисконтной карты). Меняется сумма оплат по чеку (например, частичная оплата банковской картой или бонусами), меняется состояние документа, меняются различные признаки.
Всё это делается перед началом процедуры пробития чека на кассе. Т.е. это - не сохранение чека.
А после этого - при сохранении - лишь перенос из одной таблицы в другую, и только INSERTы.

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

YuRock
GJ
Продолжаю беседу, потому что вежливый. Мне пишут, я отвечаю.
О, как Вы великодушны!

Это не великодушие, а обычная вежливость.

YuRock
GJ
Пока буду исходить из предположения, что в рамках блокирующей транзакции вносятся изменения ту же самую таблицу, которую пытается изменить запрос UPDATE.
При одной тианзакции такся ошибка невозможна.
В рамках одной транзакции можно обновлять одну и ту же запись хоть 500 раз.

т т.п.

Меня не покидает ощущение, что нард здесь просто стебётся.
Я привел выше уже полученные мною результаты. Из них понятно (если запросы к таблицам мониторинга не врут), что транзакций две, и что обе эти транзакции стартовали из моего приложения. Код приложения сложный и ветвистый. В зависимости от настроек, базы данных и даже используемых значений, может выполняться та или иная последовательность операторов. И если при каких-то условиях возникает некорректная обработка, когда проскакиваем мимо завершения одной транзакции и стартуем следующую, то не факт, что такая же последовательность выполнения операторов возникнет на другой базе, с другими настройками и с другими значениями.

* * *
ъъъъъ
Беглое изучение документации (help Delphi 2007) говорит, что <...>

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

ъъъъъ

Таки образом, поймать дедлок при такой схеме - проще некуда: ты явно стартовал транзакцию, в ее контексте сделал изменения, стартовал другую (не завершив первую транзакцию) и снова поменял ту же запись...

Когда приложение разрабатывали, старались использовать короткие транзакции. То есть старт и завершение транзакции в одной подпрограмме. Но потом код разросся (в том числе и те самые подпрограммы с транзакцией), стал более ветвистым... и где-то при каких-то условиях стал возникать ляп: то ли вообще COMMIT пропустили, то ли выполнили его с другим TTransactionDesc. Перерывать все -- это реально умереть и не встать. Сейчас вот вставил в приложение сброс в лог запросов из mon$statements, если на моменет выполнения проблемного UPDATE есть другие активные транзакции. Жаль, что там только перечень запросов, но нет порядка их выполнения (иди все же есть?). Но все же это поможет сократить пространство поиска возможного места ляпа.

[+]
ъъъъъ
Беглое знакомство с dbexpress создало впечатление, что они заточены на работу с серверами, у которых либо нет явного управления транзакциями, или одна транзакция на коннект.

У меня сложилось впечатление, что разработчики dbExpress держали в голове веб-приложения: подключились, стартовали транзакцию, открыли запрос, пробежались, создавая html-страничку, завершили работу.

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

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

GJ
Меня не покидает ощущение, что нард здесь просто стебётся.

Да, так всегда случается когда топикстартер переходит от конструктива к нытью
"слишком многа букафф, ниасилил, проста скажите на какую кнопку нажать чтобы фсё
заработало".

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 11555
GJ,

последняя попытка: если ты 100% уверен, что конкурирующая тр-ция из того же самого коннекта (а это ничем не подтверждено в данном флуде),
то никто не мешает тебе в своём приложении трассировать только свой коннект и сохранять на диск последние N MB трейс-лога в момент обнаружения конфликта.
Но для этого придётся делать некоторые телодвижения, да.

PS Обложить всё мониторингом - самая плохая идея.
21 ноя 21, 13:51    [22398635]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

Да, так всегда случается когда топикстартер переходит от конструктива к нытью

Где?
Диалог вкратце:
-- Причина ошибки в том, что запись была изменена в другой транзакции.
-- Спасибо, я знаю.
-- Блокирует другое приложение.
-- Провери вот так и так, получается, что приложение то же самое.
-- Переделай все запросы апдейт на INSERT с последующим обновлением в монопольном режиме.
-- (тут я просто в афиге и не знаю, что ответить: посоветуйте Микрософту отказаться от окон, так как в них сплошные глюки).
-- Выполните трассировку.
-- Ошибка только у заказчика, а он не позволит ничего запускать; у меня ошибка не воспроизводится.
-- Проверьте все ХП.
-- Их несколько тысяч. Можно я посмотрю только те ХП, которые выполняются в блокирующей транзакции?
-- ... и дальше по кругу.

Пардон, если кого-то пропустил :)

hvlad
GJ,
то никто не мешает тебе в своём приложении трассировать только свой коннект и сохранять на диск последние N MB трейс-лога в момент обнаружения конфликта.

Что в данном контексте означает слово "трассировать"? Запускать упомянутую выше программы трассировки? Если да, то на какой машине (я уже знаю все подводные камни :))? На компах заказчика заказчик не позволит, на моем -- ошибка не ловится.

hvlad
GJ,
Обложить всё мониторингом - самая плохая идея.

Почему все?! Я разве не говорил, что ошибка возникает только в одном месте. Именно этот один запрос UPDATE я и собираюсь мониторить.
21 ноя 21, 16:45    [22398691]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Где?
тут я просто в афиге и не знаю, что ответить
Их несколько тысяч. Можно я посмотрю только те ХП, которые выполняются в
блокирующей транзакции?

Вот именно здесь. Этими двумя пунктами ты отказываешься проделывать работу
больше определённого предела, ссылаясь, что её получится слишком много в то
время как всем остальным понятно, что паллиативом не отделаться и другого
способа нет.

GJ
Запускать упомянутую выше программы трассировки?

Нет, запускать сервис трассировки. Из своей программы. Для своей сессии.
Но чтение его результатов - тоже большая работа, так что бесперспективняк.

Posted via ActualForum NNTP Server 1.5

21 ноя 21, 17:01    [22398694]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
GJ
Я разве не говорил, что ошибка возникает только в одном месте. Именно этот один запрос UPDATE я и собираюсь мониторить.


Ватсон, это элементарно делается в своём приложении. В памяти ведётся лог вызываемых модулей и их закрытия. При возникновении ошибки лог выгружается на диск. Это даёт путь вызова "проблемного" модуля, на котором, в смысле пути, что-то пошло не так. Мне всю жизнь хватало этого, я сразу установил такой порядок оформления модулей для своей команды, забывающим запихивать в лог на create название модуля и выпихивать на destroy некоторое время напоминалось о 10% зарплаты, потом дети привыкли (С). С нормальным инструментом, в смысле управления транзакциями, и в интерфейсе SDI этого хватит и для рассматриваемого вопроса - путь конечен и просмотреть его модули недолго. С самостоятельно решающем в какой транзакции что делать и в интерфейсе MDI может оказаться недостаточно. Тогда придётся логировать и старт-финиш транзакций, а может и изменяющих запросов. Но да, если в личную технологию этот простой и логичный шаг не вструмлён изначально, таки придётся пошевелить пальцами.
21 ноя 21, 17:27    [22398707]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2668
Старый плюшевый мишка,

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

ТС попал, тут тупо и долго пахать.
21 ноя 21, 18:16    [22398730]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
GJ> Если да, то на какой машине (я уже знаю все подводные камни :))? GJ> На компах заказчика заказчик не позволит

На сервере заказчика (если у Вас нет доступа - что логично -
пообщайтесь с его ДБА - уж он-то должен быть заинтересован).

Ну или

GJ> на моем -- ошибка не ловится.

Встраивайте логгинг всего и вся в своё приложение -
сможете определить если не подробный сценарий, то
хотя бы проблемное место (модуль, процедуру и т.д.).

Posted via ActualForum NNTP Server 1.5

21 ноя 21, 20:05    [22398768]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

Гаджимурадов Рустам
Встраивайте логгинг всего и вся в своё приложение

Это ещё больше работы, чем анализ дерева процедур. Не согласится. Шибко тяжко.

Posted via ActualForum NNTP Server 1.5

21 ноя 21, 20:22    [22398776]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ggreggory
Member

Откуда:
Сообщений: 201
Мне кажется давно уже можно было с помощью IBExpert-а включить трассировку расставив нужные галочки. Делов на 5 минут, гораздо меньше чем тратить столько времени на бессмысленную переписку.
21 ноя 21, 20:47    [22398782]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

ggreggory
Мне кажется давно уже можно было с помощью IBExpert-а включить трассировку
расставив нужные галочки.

Аффтар уверяет, что давно так сделал и второй транзакции не нашёл. Может быть,
даже не врёт...

Posted via ActualForum NNTP Server 1.5

21 ноя 21, 23:06    [22398828]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Вы с Винвордом что ли обычно рнаботаете? Типа, сначала набрали доркумент, потом сохранили :)
Да, именно так. Я сначала набираю, а только потом - сохраняю.
Вы, похоже, хотите наоборот.
22 ноя 21, 00:17    [22398844]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
YuRock
GJ
Вы с Винвордом что ли обычно рнаботаете? Типа, сначала набрали доркумент, потом сохранили :)
Да, именно так. Я сначала набираю, а только потом - сохраняю.
Вы, похоже, хотите наоборот.


Насколько я понимаю, здесь речь не о популярной у неофитов методе - вставить пустую запись и потом через db-aware контролы апдейтить каждое поле по мере заполнения. А потом удивляться - а что это чтение тормозит. Но в общем случае жизненный цикл документа может измеряться неделями и уходить от апдейтов целиком невозможно. Конкретно здесь речь о статусном поле, которое может быть - подготовка, на согласовании, утверждено, выполнено, аннулировано и может ещё чорта в ступе в зависимости от детализации стадийности процесса.
22 ноя 21, 03:42    [22398857]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

GJ
Где?
тут я просто в афиге и не знаю, что ответить
Их несколько тысяч. Можно я посмотрю только те ХП, которые выполняются в
блокирующей транзакции?

Вот именно здесь. Этими двумя пунктами ты отказываешься проделывать работу
больше определённого предела, ссылаясь, что её получится слишком много в то
время как всем остальным понятно, что паллиативом не отделаться и другого
способа нет.

Я не отказываюсь, а говорю о неэффективности такого подхода. Вы, наверное, просто нее представляете себе, что такое 8 тыс. ХП чужого кода. Да и зачем просматривать все, если можно просмотреть десяток или два, которые выполнялись в блокирующей транзакции? Ведь очевидно, что причиной блокировки послужила одна из них.

Dimitry Sibiryakov

всем остальным понятно, что паллиативом не отделаться и другого
способа нет.

Отвыкайте от привычки говорить за всех. Остальные вот предлагают более оптимальные решения.

Dimitry Sibiryakov

GJ
Запускать упомянутую выше программы трассировки?

Нет, запускать сервис трассировки. Из своей программы. Для своей сессии.
Но чтение его результатов - тоже большая работа, так что бесперспективняк.

Сервис трассировки -- это что? Это какой-то экзе-файл (какой? где лежит?)? Или это сервис MS Windows (название?)?

Старый плюшевый мишка
GJ
Я разве не говорил, что ошибка возникает только в одном месте. Именно этот один запрос UPDATE я и собираюсь мониторить.


Ватсон, это элементарно делается в своём приложении. В памяти ведётся лог вызываемых модулей и их закрытия. При возникновении ошибки лог выгружается на диск. Это даёт путь вызова "проблемного" модуля, на котором, в смысле пути, что-то пошло не так. Мне всю жизнь хватало этого, я сразу установил такой порядок оформления модулей для своей команды, забывающим запихивать в лог на create название модуля и выпихивать на destroy некоторое время напоминалось о 10% зарплаты, потом дети привыкли (С). С нормальным инструментом, в смысле управления транзакциями, и в интерфейсе SDI этого хватит и для рассматриваемого вопроса - путь конечен и просмотреть его модули недолго. С самостоятельно решающем в какой транзакции что делать и в интерфейсе MDI может оказаться недостаточно. Тогда придётся логировать и старт-финиш транзакций, а может и изменяющих запросов. Но да, если в личную технологию этот простой и логичный шаг не вструмлён изначально, таки придётся пошевелить пальцами.

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

ъъъъъ
ТС попал

Так я и не стал бы лезть на форум, если бы проблема была пустяшная :)

Гаджимурадов Рустам,
Обращение к админам заказчика оставим на самый крайний случай. Сейчас буду именно логировать проблемные места и анализировать код по данным логирования.

Dimitry Sibiryakov

Гаджимурадов Рустам
Встраивайте логгинг всего и вся в своё приложение

Это ещё больше работы, чем анализ дерева процедур.

Скажите, вы точно программист? :) Нормальный программист -- существо "ленивое": напрочь отказывается заниматься рутиной, предпочитая путем хитрых программных извращений переложить выполнение рутины на комп.
И если вы внимательно читали тему, то должны были видеть, что я это уже сделал.

ggreggory
Мне кажется давно уже можно было с помощью IBExpert-а включить трассировку расставив нужные галочки. Делов на 5 минут, гораздо меньше чем тратить столько времени на бессмысленную переписку.

Запустить трассировку на пару недель на всех базах заказчика, не спрашивая разрешения заказчика? А так можно?

Dimitry Sibiryakov

ggreggory
Мне кажется давно уже можно было с помощью IBExpert-а включить трассировку
расставив нужные галочки.

Аффтар уверяет, что давно так сделал и второй транзакции не нашёл.

Естественно, не нашел. Трассировку то я выполнял (как мне здесь сказали) на локальной базе, а не на той, где появляются (иногда) две транзакции :)

YuRock
GJ
Вы с Винвордом что ли обычно рнаботаете? Типа, сначала набрали доркумент, потом сохранили :)
Да, именно так. Я сначала набираю, а только потом - сохраняю.
Вы, похоже, хотите наоборот.

Понимете, с точки зрения системы управления предприятием или системы электрнного документооборота, документ -- это не то, что вы набираете в Винворде, а сложный объект. А то, что вы набираете и сохраняете в Винворде -- не более, чем печатная форма документа. Впрочем, про это вам уже ответили.
22 ноя 21, 13:41    [22399079]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ

YuRock
пропущено...
Да, именно так. Я сначала набираю, а только потом - сохраняю.
Вы, похоже, хотите наоборот.

Понимете, с точки зрения системы управления предприятием или системы электрнного документооборота, документ -- это не то, что вы набираете в Винворде, а сложный объект. А то, что вы набираете и сохраняете в Винворде -- не более, чем печатная форма документа. Впрочем, про это вам уже ответили.
Я, похоже, мало что понимаю и вообще не точно программист, как и все в этой теме, кроме Вас.
22 ноя 21, 13:46    [22399084]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Да и зачем просматривать все, если можно просмотреть десяток или два, которые
выполнялись в блокирующей транзакции? Ведь очевидно, что причиной блокировки
послужила одна из них.

"Пони бегает по кругу и в уме круги считает..." (с)

Естественно не надо просматривать все 8к ХП, достаточно просмотреть те, которые
вызываются из твоего приложения. Разве это не очевидно?

GJ
Сервис трассировки -- это что?

Это то, что описано в README.services_extension на которые ссылается
README.trace_services: isc_action_svc_trace_start.

GJ
И если вы внимательно читали тему, то должны были видеть, что я это уже сделал.

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

Posted via ActualForum NNTP Server 1.5

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

Откуда: да, оттуда.
Сообщений: 21053
Старый плюшевый мишка
Конкретно здесь речь о статусном поле, которое может быть - подготовка, на согласовании, утверждено, выполнено, аннулировано и может ещё чорта в ступе в зависимости от детализации стадийности процесса.
Во многих случаях это отдельная таблица статусов, с фиксацией истории. Так что только хардкор insert!
22 ноя 21, 14:07    [22399101]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 21053
GJ
Речь идет о кассовом чеке.
GJ
Я говорю не про кассовы чек, который вылезает из кассового аппарата. В системе есть понятие "документ "Кассовый чек"".
"А здесь мы селёдку заворачивали".
22 ноя 21, 14:10    [22399103]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Gallemar
Member

Откуда:
Сообщений: 5683
GJ
Естественно, не нашел. Трассировку то я выполнял (как мне здесь сказали) на локальной базе, а не на той, где появляются (иногда) две транзакции :)

Ага, классическая ситуация, когда ключи надо искать где светло, а не там где потеряли...
И он удивляется тому, что Сибиряков его троллит. Трассировка нужна там, где ситуация воспроизводится, тем более в ситуации с deadlock. Поэтому вопрос "Скажите, вы точно программист? :) " - надо задать самому себе.
22 ноя 21, 14:11    [22399105]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54805
Gallemar
Ага, классическая ситуация, когда ключи надо искать где светло, а не там где
потеряли...
И он удивляется тому, что Сибиряков его троллит.

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

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

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

Откуда:
Сообщений: 5683
Dimitry Sibiryakov
Gallemar
Ага, классическая ситуация, когда ключи надо искать где светло, а не там где
потеряли...
И он удивляется тому, что Сибиряков его троллит.

Вообще-то если бы ты прочитал топик, то увидел, что совет трассировать на локальной базе дал именно я.

Я по диагонали проглядел топик. Ладно, первый шаг он сделал, ничего не нашел и успокоился?
22 ноя 21, 14:26    [22399115]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

Gallemar
Ладно, первый шаг он сделал, ничего не нашел и успокоился?

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

Posted via ActualForum NNTP Server 1.5

22 ноя 21, 14:34    [22399123]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Gallemar
Member

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

я тут с попкорном и вувузелой.

А пиво?
22 ноя 21, 14:36    [22399124]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

Пиво - по субботам.

Posted via ActualForum NNTP Server 1.5

22 ноя 21, 14:51    [22399128]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ggreggory
Member

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

Сервис трассировки -- это что? Это какой-то экзе-файл (какой? где лежит?)? Или это сервис MS Windows (название?)?


Если не хотите изучать тему и если у вас русскоязычный заказчик - уговорите его установить программу IBExpert, она для русскоязычных пользователей бесплатна. В ней Services, Trace and audit.

К сообщению приложен файл. Размер - 18Kb
22 ноя 21, 15:00    [22399133]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

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

Не понял, что здесь понимается под словом "модуль".


А Вы точно программист? (C) Насколько я понял, Вы работаете с Delphi. Так вот, там есть такое понятие Unit. Чаще всего содержит объект типа TForm, предназначенный для предоставления пользователю некоторого интерфейса. В результате действий пользователя с помощью этого интерфейса в обработчиках событий, связанных с визуальными контролами (это всякие кнопочки и тому подобное) выполняются в том числе старты и завершения транзакций и запросы к базе. Как-то такЪ.
22 ноя 21, 16:59    [22399204]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
Может, он просто тролль?...

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 50
YuRock
Я, похоже, мало что понимаю и вообще не точно программист, как и все в этой теме, кроме Вас.

Прекращайте говорить за всех, говорите за себя. Есть в этой теме люди, которые нормально отвечают.

Dimitry Sibiryakov

Естественно не надо просматривать все 8к ХП, достаточно просмотреть те, которые
вызываются из твоего приложения. Разве это не очевидно?

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

Dimitry Sibiryakov

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

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

Gallemar
И он удивляется тому, что Сибиряков его троллит.

Так это оказывается троллинг был?! Теперь понятно... а то я думаю, что за идиотизм :)

ggreggory, спасибо. Теперь понятно.
IBExpert-ом я, конечно же, пользуюсь, но в сервисы не лазил. Надо будет посмотреть при случае.

Старый плюшевый мишка
GJ

Не понял, что здесь понимается под словом "модуль".


А Вы точно программист? (C) Насколько я понял, Вы работаете с Delphi. Так вот, там есть такое понятие Unit.

Слово "модуль" является шибко многозначниым как в русском языке вообще, так и в IT в частности. Поэтому я и попросил вас уточнить, что именно подразумевается под словом "модуль" в вашем сообщении. Если паскалевский UNIT, то тогда странно... плохо стыкуется с фразой "лог вызываемых модулей и их закрытия". Unit вызывается компилятором, потом скомпилированный вариант вызывается линкером, после чего его код интегрируется в единый исполняемый файл, и там уже никаких вызовов "модуля" нет.

* * *
Еще один маленький вопрос по dbExpress. Понимаю, что не по теме, так как здесь специалисты по Firebird, но все же... вдруг кто-то знает... Мы можем открыть запрос не стартуя явно транзакцию. При этом в Firebird транзакция создается автоматом, но в приложении TSQLConnection.InTransaction остается false. Собственно, а какова дальнейшая судьба этой транзакции? Она будет болтаться до закрытия соединения?
Вопрос не критичный (любопытство), поэтому специально рыть не нужно. Просто на тот случай, если кто-то уже сталкивался и знает.
23 ноя 21, 11:07    [22399559]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

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



Firebird никогда сам не создаёт транзакции. Да есть СУБД в которых если ты не стартовал транзакцию, то при первом выполнении запроса она сама стартует. НО это не случай ФБ. В Firebird страт транзакции (за исключением автономных транзакций) всегда происходит со стороны клиента.
Так что насчёт автоматического старта транзакций это вопросы к dbExpress. Ещё раз повторяю Firebird это точно не делает.
23 ноя 21, 11:15    [22399563]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2668
GJ
Мы можем открыть запрос не стартуя явно транзакцию. При этом в Firebird транзакция создается автоматом, но в приложении TSQLConnection.InTransaction остается false. Собственно, а какова дальнейшая судьба этой транзакции?

После выполнения запроса созданная транзакция завершается, тоже автоматически. Что на нижнем уровне - неизвестно, исходники "драйвера" firebird недоступны.
23 ноя 21, 11:16    [22399564]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

Откуда:
Сообщений: 2668
Симонов Денис
Firebird никогда сам не создаёт транзакции.

Фаерберд не создает, dbexpress - создает.
23 ноя 21, 11:17    [22399566]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

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

я тут как и почти все dbExpress знаю чуть меньше чем никак.
Что как и когда он создаёт мне не ведомо. Как тут уже сказали dbExpress это не удачная реинкарнация BDE.
То же с закрытыми исходниками драйверов и с глюками, которые сам уже не исправишь.
23 ноя 21, 11:26    [22399573]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

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

данную тему можно как историю о применении dbexpress, детей пугать...
23 ноя 21, 11:56    [22399580]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

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

Слово "модуль" является шибко многозначниым как в русском языке вообще, так и в IT в частности. Поэтому я и попросил вас уточнить, что именно подразумевается под словом "модуль" в вашем сообщении. Если паскалевский UNIT, то тогда странно... плохо стыкуется с фразой "лог вызываемых модулей и их закрытия". Unit вызывается компилятором, потом скомпилированный вариант вызывается линкером, после чего его код интегрируется в единый исполняемый файл, и там уже никаких вызовов "модуля" нет.


Да-да-да. И даже собственно исходники программы - это на самом деле набор ноликов и единичек.

Точно тролль.
23 ноя 21, 12:54    [22399627]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

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

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

Posted via ActualForum NNTP Server 1.5

23 ноя 21, 13:07    [22399640]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1454
Старый плюшевый мишка

Точно тролль.

Не противился наш серенький насилию злом,
И сносил побои весело и гордо!! (с))
Чего не набросились на человека, он ни разу не тролль. Я его знаю.
И компанию эту знаю. И, если уж на то пошло, и Кузьменко с Ковязиным ее знают.
Поговорить вот любит, это да. Сказывается многолетний опыт модерирования Королевства Delphi.))
23 ноя 21, 13:24    [22399650]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
WildSery
Member

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

Опыт модерирования не развивает желания поговорить.
23 ноя 21, 14:45    [22399692]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1454
WildSery,

Бу-бу-бу. От человека зависит. И от модерируемого ресурса. Имхо.))
23 ноя 21, 14:53    [22399700]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
WildSery
Member

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

Не был в "королевстве дельфи", неужели там всё так плохо.
23 ноя 21, 16:33    [22399765]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
eSem
Member

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

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

Да, такая транзакция будет висеть до закрытия соединения с БД.
Чем она закончится можно посмотреть в таблице MON$TRANSACTIONS колонки MON$AUTO_COMMIT и MON$AUTO_UNDO. Встроенный драйвер dbExpress D7 для всех транзакции выставляет значения (0, 1), соотвественно.
23 ноя 21, 17:18    [22399801]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
WildSery
Vlad F,

Опыт модерирования не развивает желания поговорить.


Я бы даже сказал - уменьшает такое желание На "своём ресурсе" :)
23 ноя 21, 17:20    [22399804]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
Vlad F
Старый плюшевый мишка

Точно тролль.

Не противился наш серенький насилию злом,
И сносил побои весело и гордо!! (с))
Чего не набросились на человека, он ни разу не тролль. Я его знаю.
И компанию эту знаю. И, если уж на то пошло, и Кузьменко с Ковязиным ее знают.
Поговорить вот любит, это да. Сказывается многолетний опыт модерирования Королевства Delphi.))


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

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

Откуда: Донецк
Сообщений: 4940
eSem
GJ

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

Да, такая транзакция будет висеть до закрытия соединения с БД.
Чем она закончится можно посмотреть в таблице MON$TRANSACTIONS колонки MON$AUTO_COMMIT и MON$AUTO_UNDO. Встроенный драйвер dbExpress D7 для всех транзакции выставляет значения (0, 1), соотвественно.
:)
23 ноя 21, 17:24    [22399811]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
Старый плюшевый мишка
WildSery> Опыт модерирования не развивает желания поговорить.

Я бы даже сказал - уменьшает такое желание На "своём ресурсе" :)

+1
Хотя от человека зависит, конечно -
может, ему общения в жизни не хватает.

Posted via ActualForum NNTP Server 1.5

23 ноя 21, 17:31    [22399816]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
Гаджимурадов Рустам
Старый плюшевый мишка
WildSery> Опыт модерирования не развивает желания поговорить.

Я бы даже сказал - уменьшает такое желание На "своём ресурсе" :)

+1
Хотя от человека зависит, конечно -
может, ему общения в жизни не хватает.


Я по своему опыту. Модераторство накладывает самоограничения. В смысле - чтоб не выглядеть царьком, которому можно всё что другими нельзя. И от этого становится скушнааа... И идёшь флудить где-нить в сторонке
23 ноя 21, 17:35    [22399820]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 2093
Vlad F
Чего не набросились на человека, он ни разу не тролль. Я его знаю.
И компанию эту знаю.

ну так это все меняет!
23 ноя 21, 17:37    [22399823]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
Дегтярев Евгений> ну так это все меняет!

... послышались нотки из Райкина...

Posted via ActualForum NNTP Server 1.5

23 ноя 21, 17:38    [22399825]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Дегтярев Евгений
Member

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

напомни
23 ноя 21, 17:44    [22399830]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

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

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

И я не был (и по-моему оно, вообще, давно почило в бозе), это из личных разговоров 15-летней давности.
Все это к тому что у него достаточно длительный опыт Delphi-разработки, но академического плана, не DB-aware направления.
А сейчас чел попал, оставшись, как понимаю, практически один в антигуманном DBX-окружении, - все кто это в свое время (наш)кодил разбежались.
23 ноя 21, 17:59    [22399841]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
Дегтярев Евгений
Гаджимурадов Рустам,

напомни
Ну дык это - "В принципе ты прав... Но по существу ты глубоко ошибаешься!" и т.д.
23 ноя 21, 18:02    [22399844]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1454
Старый плюшевый мишка

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

Может и слышит, да не может пока воплотить.
Ты же видишь какие были последние вопросы про DBX-транзакции.
Тем более без предварительного опыта на BDE или хотя бы том же IBX.
23 ноя 21, 18:05    [22399851]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
ъъъъъ
Member

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

Это всё "академический план".
23 ноя 21, 18:06    [22399852]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
Если не получается - пусть контора заплатит кому-нибудь
деньги, кто будет в этом копаться и решать проблему.
Наверняка, получится быстрее.

Posted via ActualForum NNTP Server 1.5

23 ноя 21, 18:14    [22399856]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
Тем более если они с Димой уже знакомы.
Сам он не возьмётся, наверное, - перепоручит
кому-нибудь другому. Паше там или ещё кому-то.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 1454
Не возражаю. Пусть заплатит, пусть перепоручит.))
Сам бы посоветовал все это на IBX перевести. На FireDAC, наверное, пороху уже не хватит.

Сообщение было отредактировано: 23 ноя 21, 18:26
23 ноя 21, 18:24    [22399865]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11555
eSem
Да, такая транзакция будет висеть до закрытия соединения с БД.
Откуда это известно ?

eSem
Чем она закончится можно посмотреть в таблице MON$TRANSACTIONS колонки MON$AUTO_COMMIT и MON$AUTO_UNDO. Встроенный драйвер dbExpress D7 для всех транзакции выставляет значения (0, 1), соотвественно.
Ну а это тут при чём ?
23 ноя 21, 18:30    [22399869]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
Vlad F> Сам бы посоветовал все это на IBX перевести.

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

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 2668
Гаджимурадов Рустам
Vlad F> Сам бы посоветовал все это на IBX перевести.

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

Вот и растут зарплаты дельфистов...
23 ноя 21, 18:40    [22399879]     Ответить | Цитировать Сообщить модератору
 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]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896
GJ
Если не прокатит, и моя "ловушка" окажется пуста, буду логировать все старты и завершения транзакций.
давно надо было, раз уж не хочешь пользоваться трейсом самого сервера.
обрати внимание, при конфликте сервер выдёт тебе номер конфликтующей транзакции - будет на куда посмотреть.
24 ноя 21, 17:48    [22400328]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
GJ
Вывод: чтобы произошла блокировка блокирующая транзакция не должна быть завершена на момент выполнения запроса UPDATE в другой транзакции.


ошибаешься, по крайней мере до 4.0 это не обязательно так. Да и в 4.0 зависит какой именно RC ты стартуешь
24 ноя 21, 18:05    [22400335]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

Так оно и есть, если клиент работает непосредственно с таблицами. А если подготовить специальные ХП, то сбоя в работе пользователь получит сообщение, что данный документ правится другим пользователем, и внесение в него изменений невозможно.
Не зна, при чем здесь "работать непосредственно с таблицами" или через процедуру.
Ты, кажется, говорил, что UPDATE'ов этой таблицы - тысячи в разных местах.
Все они обложены такими "спец. процедурами"?
И что в тех "специальных процедурах"? Добавление записей в какую-то таблицу локов?
И как это делается? В одной транзакции, или потом мусор подчищать приходится?
24 ноя 21, 19:01    [22400375]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

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

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

Доктор, ну вот нафига же так тупить и подставляться?! Я выполнил определенную последовательность действий и получил определенный результат. И все это описал. Даже если я не знаю, что такое "уровни изоляции", то результат говорит сам за себя: существуют такие уровни изоляции, при которых мои утверждения являются истинными. Потом, если потребуется, можно будет посмотреть в моем IBExpert настройки и узнать, что данное поведение имеет место для транзакций READ COMMITTED.
Хотите меня смутить, скажите, что тут раз на раз не приходится: может получится, а может и нет. И вот тогда я вынужден буду заткнуться, потому что данное утверждение я не смогу опровергнуть экспериментально ;)

YuRock
GJ
пропущено...

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

Упустил в моем сообщении еще один кусок текста: "А если разработать специальное клиентское приложение, то там пользователь даже открыть документ на редактирование не сможет, получит то самое сообщение, что документ пока занят".
Приложения нашей системы так устроены, что пользователь просто не сможет открыть документ "на редактирование", если другой пользователь его уже открыл. Поэтому мне главное самому не напортачить с транзакциями, а никто посторонний помешать не сможет.
Конечно же, за исключаем вмешательства грамотного человека с использованием IBExpert-а :) Но против лома нет приема.
24 ноя 21, 19:44    [22400390]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
существуют такие уровни изоляции, при которых мои утверждения являются истинными.

Да, существуют. Но в этом топике ты так и не удосужился упомянуть используются
ли в твоём приложении именно они.

Posted via ActualForum NNTP Server 1.5

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

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

GJ
существуют такие уровни изоляции, при которых мои утверждения являются истинными.

Да, существуют. Но в этом топике ты так и не удосужился упомянуть используются
ли в твоём приложении именно они.

В приложении используются транзакции только такие, в которых
TTransactionDesc.IsolationLevel = xilREADCOMMITTED

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

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

GJ
В приложении используются транзакции только такие, в которых
TTransactionDesc.IsolationLevel = xilREADCOMMITTED

В какие точно флаги Firebird это транслируется внутри драйвера?
Ты трассировал транзакции, ты должен это знать.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 5683
Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс.
24 ноя 21, 20:52    [22400405]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
hvlad
Member

Откуда:
Сообщений: 11555
Gallemar
Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс.
При пожирании кактусов время летит незаметно ;)
24 ноя 21, 21:18    [22400415]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1454
Вы просто ещё не поняли с кем связались.
Он здесь любого перенудит влегкую, имхо.))

Сообщение было отредактировано: 24 ноя 21, 22:34
24 ноя 21, 22:28    [22400433]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

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

P.S. Простите за занудство.

Posted via ActualForum NNTP Server 1.5

24 ноя 21, 22:40    [22400437]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

Gallemar
А надо всего лишь запустить трейс.

Топикстартеры на такое обычно отвечают "запускал, не помогло".

Posted via ActualForum NNTP Server 1.5

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

Откуда: Донецк
Сообщений: 4940
GJ


YuRock
пропущено...
Не зна, при чем здесь "работать непосредственно с таблицами" или через процедуру.
Ты, кажется, говорил, что UPDATE'ов этой таблицы - тысячи в разных местах.

Упустил в моем сообщении еще один кусок текста: "А если разработать специальное клиентское приложение, то там пользователь даже открыть документ на редактирование не сможет, получит то самое сообщение, что документ пока занят".
Приложения нашей системы так устроены, что пользователь просто не сможет открыть документ "на редактирование", если другой пользователь его уже открыл. Поэтому мне главное самому не напортачить с транзакциями, а никто посторонний помешать не сможет.
Конечно же, за исключаем вмешательства грамотного человека с использованием IBExpert-а :) Но против лома нет приема.

Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).
Там и еще были вопросы, но ты всё "упустил".

Сообщение было отредактировано: 24 ноя 21, 23:20
24 ноя 21, 23:19    [22400445]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
Vlad F
Вы просто ещё не поняли с кем связались.
Он здесь любого перенудит влегкую, имхо.))


Лично я уже понял :) Кормить тролля больше не намерен. А порассуждать можно

Во-первых, я не очень понимаю почему FB до сих пор с лёгкой руки Пресвятого Джима любой конфликт величает дедлоком. Ещё меньше я понимаю может ли движок опознать дедлок. И уж совсем не понимаю должен ли он этим заниматься. Мне каатся не его это движково дело.

Во-вторых, если опустить головотяпство и разгильдяйство при управлении транзакциями, особенно стартуемыми и завершаемыми неестественным интеллектом, что действительно ставит гомосапиенса раком в затруднительные обстоятельства, а также перенасыщение бизнес-логикой триггеров и хранимок, то лок конфликт - это совершенно штатная ситуация в боле-мене сложных системах. И он не враг, а друг, так к нему и надо относиться и штатно обслуживать ситуации в которых он возникает.

Вот представим себе, скажем, автобазу, у которой на сегодня осталась одна свободная машина. Трое менеджеров одновременно снимают трубки, реагируя на звонки клиентов, и начинается конкуренция за ресурс. В результате двое получают конфликт. Как его разрешать - не Железного Майка дело, это не алгоритмизируется. Коллеги, получив извещение о ситуёвине, должны возопить и промеж собой решить кому отдать предпочтение, потому что один из клиентов уж очень вонюч и темя проклюёт через начальство, другой постоянный партнёр, отпускать коего искать альтернативы, к которым он может уйти насовсем, нежелательно, а третий, который, вполне возможно, и оказался в очередушке первым, типа "мужик один приходил". Вопрос о том, в какой момент захватывать ресурс - при первом обращении к нему или завершающем мазке кистью - оставим в сторонке, это тема отдельного холивара, по которой всё что имел сказать, я сказал лет 15-20 назад.

Или. О статусных полях. Ну какого лешего менеджеру работать с документом, если, пока он его разглядывал, Биг Босс поставил резолюцию - нах. Пусть при первом же телодвижении получит конфликт, перечитает данные, узрит резолюцию и расслабится.

Есть ещё категория неизбежного зла. Приехал на склад вагон о 60 тоннах груза, например, дизайнерской полосато-волосатой бумаги из слонячьего говна, которую, в смысле каждую отдельную разновидность которой, сиречь номенклатурную позицию, оптовик берёт по две-три пачки на месяц. Весом по 2-3 кило пачка. Сколько там позиций в вагоне, считайте сами Грузчики носятся, кладовщик регистрирует состав складской операции приёмки, трали-вали-пассатижи. И вот наступает момент регистрации завершения операции. Тоиссь, пометки транспортной партии как неживой, увеличения складского запаса по всей этой туевой хуче номенклатурных позиций, отстрела в ценовые группы номенклатурных позиций количеств и цен для информирования коммерческого директора и прочих мыслящих группами, а не отдельными позициями, усреднения себестоимости по группам, изменения резервов на складе, в смысле под кого из потребителей что и сколько везли, снятие оных из транспортной партии и ещё чорта в ступе. Короче, текст ХП в максимальный размер блоба в системной таблице не влезает, приходится дробить. Дык оно ж минут 10 будет выполняться. На железе образца 5-го году. Не пугайтесь, не тыща девятьсот пятого. И за эти 10 минут чтоб другой кладовщик попытался зарегистрировать отгрузку одной пачки пусть даже не из присутствовавших в вагоне номенклатурных позиций, но входящих с ними в одну ценовую группу - да нефиг делать. И будет ему облом-с. В смысле Железный Майк раз 5 рестартует транзакцию и потыкается, а потом скажет - знаешь дорогой, занято. Пойди покури или там соточку накати и ущипни соседку-кладовщицу за жопу. А вот если он начал свою регистрацию отгрузки, в смысле транзакцию стартовал, раньше старта транзакции завершения приёмки, то это хуже, 10 минут превращаются в 20 если случилось сие на последней принимаемой позиции. Но деваться некуда. Умный человек это всё в приращениях делает, а не пишет в базу посчитанные за щекой новые значения, можно было бы и пропустить, но сервер не умеет оценивать IQ программиста и подходит к вопросу пессимистически. И правильно делает. Ситуация возникает нечасто, но необратимо, с этим надо примириться и обслуживать её.

Чёта я раззвезделся на ночь глядя...
25 ноя 21, 00:41    [22400449]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

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

Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).


Если с мудрствованиями лукавыми, то http://www.ibase.ru/pslock/

По-армейски коротко и ясно http://www.ibase.ru/plocks/
25 ноя 21, 00:52    [22400452]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
Старый плюшевый мишка
YuRock

Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).


Если с мудрствованиями лукавыми, то http://www.ibase.ru/pslock/
Спасибо, я знаю разные способы, но хотел узнать, как реализовано у топикстартера.
Кстати, по этой ссылке его способов нет, ибо у него сообщеается, каким пользователем заблокировано. SELECT FOR UPDATE для этого не поможет.

Старый плюшевый мишка
По-армейски коротко и ясно http://www.ibase.ru/plocks/

А вот тут якобы есть (вариант 2), но написано странно, сырой материал какой-то:
1. Не сказано, что после успешного Lock надо транзакцию закоммитить (иначе ошибка будет как минимум не такой красивой, а просто обычный lock conflict);
2. Не сказано, что если запустить других клиентов под тем же пользователем, то этот способ не поможет, а будет вообще кошмар - последовательные неосознанные изменеия одного и того же, с еще бОльшей вероятностью нарваться на lock conflict-ы, ведь транзакций нужно 2 и 3 апдейта (или insert/update/delete, если через доп. таблицу).
3. Все проблемы пункта 2 с успехом повторятся, если запустить какое-нибудь (например, авто-) редактирование документа второй раз в этом же клиенте примерно параллельно.

Сообщение было отредактировано: 25 ноя 21, 06:10
25 ноя 21, 06:06    [22400466]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 63467
СПМ> Во-первых, я не очень понимаю почему FB
СПМ> до сих пор любой конфликт величает дедлоком.

Обратная совместимость, вероятно.
Хотя с другой стороны, как водится, можно ввести
соотв. переходный ключик и переименовывать.

С третьей стороны, непонятно, нафига оно нужно...

Posted via ActualForum NNTP Server 1.5

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

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

GJ
В приложении используются транзакции только такие, в которых
TTransactionDesc.IsolationLevel = xilREADCOMMITTED

В какие точно флаги Firebird это транслируется внутри драйвера?

Пардон за шаблонный ответ, но с какой целью интересуетесь? Это имеет какое-то отношение к теме, или просто поговорить? Так меня и так обвиняют в тоннах флуда. Если интересно, сооруди тестовую программу и посмотри.

Gallemar
Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс.

Ну, наверное мышкам просто нравится здесь флудить общаться, потому что я открытым тестом уже давно сказал, что вопросов по теме больше не имею.
Про сложности трейса в данном случае я уже упоминал. Десять баз, по 15 моих приложений на каждой. Плюс куча других приложений, работающих с той же базой. И прошла неделя, а ошибка еще не появилась. То есть всю эту неделю надо было с утра запускать трассировку на каждой БД. По уму, надо бы аудит настроить на серверах, но без админов заказчика этого не сделать.

Vlad F
Вы просто ещё не поняли с кем связались.
Он здесь любого перенудит влегкую, имхо.))

Ты мне льстишь :) Судя по обсуждению, как минимум парочка участников мне ничуть не уступает.
Или ты под занудством понимаешь спокойное ведение беседы, игнорируя многочисленные подъё... подколки и троллинг? :)

Dimitry Sibiryakov

Топикстартеры на такое обычно отвечают "запускал, не помогло".

Уже обсуждалось, уже ответили. Мне посоветовали выполнить трассировку на локальной БД на своем компе, на что я ехидно ехидно ответил, что не помогло. А как оно могло помочь, если проблемы возникают только на базах заказчика. Причем, только одного заказчика?!

YuRock
Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да).
Там и еще были вопросы, но ты всё "упустил".

Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко.

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

Старый плюшевый мишка

Лично я уже понял :) Кормить тролля больше не намерен.

Написал человек и разродился огроменным постом по поводу блокировок при многопользовательской работе в теме, касающейся поиску ошибок в приложении, приводящих к возникновению блокировок при однопользовательской работе.
Кажется, я перестаю понимать, что такое троллинг :)
25 ноя 21, 23:10    [22400976]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Dimitry Sibiryakov
Member

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

GJ
Пардон за шаблонный ответ, но с какой целью интересуетесь? Это имеет какое-то
отношение к теме, или просто поговорить?

Ещё раз, медленно: сабжевая ошибка может возникать в нескольких ситуациях:
1) update одной записи при всех уровнях изоляции.
2) select изменённой записи при уровне изоляции read committed no record version.
3) select for update.

Во втором случае ты хоть затрассируйся update - ничего не найдёшь.

GJ
Мне посоветовали выполнить трассировку на локальной БД на своем компе, на что я
ехидно ехидно ответил, что не помогло. А как оно могло помочь, если проблемы
возникают только на базах заказчика. Причем, только одного заказчика?!

Эта трассировка должна была выявить реальную последовательность работы
приложения с БД и предоставить полный список изменяемых таблиц на которых
способен происходить конфликт. Но не помогло так не помогло. Значит, не судьба.

Posted via ActualForum NNTP Server 1.5

25 ноя 21, 23:20    [22400979]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко.

К данному обсуждению это все равно относится слабо
Очень вероятно, что этот механизм имеет прямое отношение к проблеме. Возможно, и создаёт её. Потому и спрашивал.
Тут тебе и лишние транзакции, которые можно забыть не открыть или закрыть, тут всё.
Но если тебе не интересно - ок. Мне - тем более. Я заранее знаю, как оно у тебя устроено, просто тебя хотел на мысль навести, где проблему возможную искать.
25 ноя 21, 23:40    [22400983]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Gallemar
Member

Откуда:
Сообщений: 5683
GJ
Ну, наверное мышкам просто нравится здесь флудить общаться, потому что я открытым тестом уже давно сказал, что вопросов по теме больше не имею.

Тогда имеет смысл прибить автора тему и разойтись
26 ноя 21, 09:00    [22401074]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Vlad F
Member

Откуда:
Сообщений: 1454
Gallemar,

Погодите прибивать, можно просто ослабить давление.
Он же должен в конце концов сообщить, чем там кончится дело.))
26 ноя 21, 10:44    [22401118]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
GJ
Member

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

Эта трассировка должна была выявить реальную последовательность работы
приложения с БД и предоставить полный список изменяемых таблиц на которых
способен происходить конфликт.

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

YuRock
GJ
Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко.

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

Либо я не понял тебя, либо ты не понял меня.
В БД существует специальная таблица, в которую заносится информация о том, что такой-то пользователь "открыл на редактирование такой-то документ" (в кавычках, потому что это условно-упрощенно, чтобы не вдаваться в детали). Соответственно, другое приложение не позволит открыть документ на редактирование, если он уже кем-то открыт. Таблица с содержательными данными при этом не блокируется, поэтому и говорю, что к обсуждаемому вопросу это отношения не имеет.

Gallemar

Тогда имеет смысл прибить автора тему и разойтись

Ну... я, как бы, уже предлагал это. Не прибить, конечно, а просто закончить обсуждение. Но народ все пишет и пишет.

Vlad F
Gallemar,
Погодите прибивать, можно просто ослабить давление.
Он же должен в конце концов сообщить, чем там кончится дело.))

Ждать, скорее всего, придется долго. Я где-то через недельку выпадаю из общения (по медицинским аспектам) до нового года. Так что тема заглохнет сама собой и уползет вниз.
26 ноя 21, 11:40    [22401151]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Gallemar
Member

Откуда:
Сообщений: 5683
GJ
Так что тема заглохнет сама собой и уползет вниз.

Придешь и апнешь :) и всё снова как завертится...
26 ноя 21, 11:45    [22401158]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4940
GJ
Либо я не понял тебя, либо ты не понял меня.
В БД существует специальная таблица, в которую заносится информация о том, что такой-то пользователь "открыл на редактирование такой-то документ" (в кавычках, потому что это условно-упрощенно, чтобы не вдаваться в детали). Соответственно, другое приложение не позволит открыть документ на редактирование, если он уже кем-то открыт.

Это достигается путём открытия еще одной транзакции, перед редактированием документа. И коммитом этой транзакции.
Если забыть ее закоммитить - считай, что в ту таблицу ничего не добавляется, другие пользователи эту блокировку не увидят, и получим твою ситуацию - одновременное обновление документа.
Эта только одна из возможностей.
Вторая (я уже писал, но ты как будто не читал) - если "другое приложение" запущено под тем же пользователем, то оно, скорее всего, тоже разрешит обновлять документ (не знаю, как там у тебя, но обычно делается так, чтобы вообще хоть кто-то мог его доредактировать в случае сбоя). И тогда опять получаем твою ситуацию - возможность одновременного обновления документа.
GJ
Таблица с содержательными данными при этом не блокируется
Это имеет значение, но этого не достаточно.
GJ
поэтому и говорю, что к обсуждаемому вопросу это отношения не имеет.
Имеет непосредственное, как видишь.
26 ноя 21, 11:53    [22401166]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

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

А вот тут якобы есть (вариант 2), но написано странно, сырой материал какой-то:


Да, действительно фигня какая-то. Я до конца не дочитал, подумал что это про классическую отдельную таблицу 1:1 для конфликтов без порождения версий содержательной записи.
26 ноя 21, 18:15    [22401450]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 1134
Старый плюшевый мишка
YuRock

А вот тут якобы есть (вариант 2), но написано странно, сырой материал какой-то:


Да, действительно фигня какая-то. Я до конца не дочитал, подумал что это про классическую отдельную таблицу 1:1 для конфликтов без порождения версий содержательной записи.


Ещё подумал. Могу предположить только, что там схема такая:
1. При создании записи в основной таблице триггер порождает сателлита ID-USER-TAIMSTAMP c null в артибутах. Ни основная запись, ни сателлитная никому не видны до завершения транзакции и на первичной вставке никто не влезет.
2. При редактировании сначала стартуется служебная транзакция, в которой выполняется нечто вроде его LockRecord, только select для выдачи сообщения выполняется по if RowsAffected=0 и сомнительный в смысле работы под одним аккаунтом с нескольких точек if LockUser<>USER там не нужен. Служебная транзакция коммитится, чтобы вывеска "Занято Васей Пупкиным" была видна всем поступающим аналогично, в случае успеха стартуется основная и поехали. Сбрасываются атрибуты сателлитной записи в основной транзакции перед её завершением.

Но.

Во-первых, вероятность бесконфликтного выполнения блокировки зависит от интенсивности возникновения попыток одновременного доступа в бизнес-логике организации процесса и равна той же вероятности при прямой блокировке основной. То есть, конфликт всё равно надо обслуживать, он просто переходит с основной записи на сателлитную, в момент её апдейта.

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

В-третьих, если объект чуть сложнее палки и верёвки, доступ ко всем элементам его состава/составов (детализация возможна по нескольким критериям) должен осуществляться строго по этой схеме через заголовок, в том числе из триггеров других таблиц и всяких хранимок. Что, как сказал один мудрец, is the road to hell Это относится не только к этой схеме, а к пессимистическим блокировкам в принципе, смысл применения которых сильно зависит от массы причин. It, как говорится, depends.
27 ноя 21, 00:17    [22401593]     Ответить | Цитировать Сообщить модератору
 Re: Firebird + fbExpress lock conflict  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8878
Старый плюшевый мишка
Во-вторых, в случае падения приложения, окончания току в розетке компа юзера, взмаха швабры уборщицы по проводам в хабе и тэ пэ в сателлитной таблице остаются мусорные записи, которые не дадут добраться до документа никому, в том числе и этому юзеру после перезахода.
Триггер на дисконнект вполне решает все означенные проблемы. Но есть падения сервера... они очень сильно реже (серверные упсы обычно получше десктопных) и таки потребуют вмешательства админа.
27 ноя 21, 14:00    [22401794]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9      [все]
Все форумы / Firebird, InterBase Ответить