|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJ Если не прокатит, и моя "ловушка" окажется пуста, буду логировать все старты и завершения транзакций. обрати внимание, при конфликте сервер выдёт тебе номер конфликтующей транзакции - будет на куда посмотреть. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 17:48 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJВывод: чтобы произошла блокировка блокирующая транзакция не должна быть завершена на момент выполнения запроса UPDATE в другой транзакции. ошибаешься, по крайней мере до 4.0 это не обязательно так. Да и в 4.0 зависит какой именно RC ты стартуешь ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 18:05 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJВывод: чтобы произошла блокировка блокирующая транзакция не должна быть завершена на момент выполнения запроса UPDATE в другой транзакции. Вывод номер два: пациент не в курсе, что у транзакций бывают разные уровни изоляции при которых их поведение тоже бывает разным. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 18:52 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJ YuRockТак ведь так и есть. При insert блокировки невозможны, при update - возможны. Делаешь логику на insert - и не паришься вообще о блокировках. Так оно и есть, если клиент работает непосредственно с таблицами. А если подготовить специальные ХП, то сбоя в работе пользователь получит сообщение, что данный документ правится другим пользователем, и внесение в него изменений невозможно.Не зна, при чем здесь "работать непосредственно с таблицами" или через процедуру. Ты, кажется, говорил, что UPDATE'ов этой таблицы - тысячи в разных местах. Все они обложены такими "спец. процедурами"? И что в тех "специальных процедурах"? Добавление записей в какую-то таблицу локов? И как это делается? В одной транзакции, или потом мусор подчищать приходится? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 19:01 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov GJВывод: чтобы произошла блокировка блокирующая транзакция не должна быть завершена на момент выполнения запроса UPDATE в другой транзакции. Вывод номер два: пациент не в курсе, что у транзакций бывают разные уровни изоляции при которых их поведение тоже бывает разным. Доктор, ну вот нафига же так тупить и подставляться?! Я выполнил определенную последовательность действий и получил определенный результат. И все это описал. Даже если я не знаю, что такое "уровни изоляции", то результат говорит сам за себя: существуют такие уровни изоляции, при которых мои утверждения являются истинными. Потом, если потребуется, можно будет посмотреть в моем IBExpert настройки и узнать, что данное поведение имеет место для транзакций READ COMMITTED. Хотите меня смутить, скажите, что тут раз на раз не приходится: может получится, а может и нет. И вот тогда я вынужден буду заткнуться, потому что данное утверждение я не смогу опровергнуть экспериментально ;) YuRock GJ пропущено... Так оно и есть, если клиент работает непосредственно с таблицами. А если подготовить специальные ХП, то сбоя в работе пользователь получит сообщение, что данный документ правится другим пользователем, и внесение в него изменений невозможно. Ты, кажется, говорил, что UPDATE'ов этой таблицы - тысячи в разных местах. Упустил в моем сообщении еще один кусок текста: "А если разработать специальное клиентское приложение, то там пользователь даже открыть документ на редактирование не сможет, получит то самое сообщение, что документ пока занят". Приложения нашей системы так устроены, что пользователь просто не сможет открыть документ "на редактирование", если другой пользователь его уже открыл. Поэтому мне главное самому не напортачить с транзакциями, а никто посторонний помешать не сможет. Конечно же, за исключаем вмешательства грамотного человека с использованием IBExpert-а :) Но против лома нет приема. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 19:44 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJсуществуют такие уровни изоляции, при которых мои утверждения являются истинными. Да, существуют. Но в этом топике ты так и не удосужился упомянуть используются ли в твоём приложении именно они. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 19:48 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov GJсуществуют такие уровни изоляции, при которых мои утверждения являются истинными. Да, существуют. Но в этом топике ты так и не удосужился упомянуть используются ли в твоём приложении именно они. В приложении используются транзакции только такие, в которых TTransactionDesc.IsolationLevel = xilREADCOMMITTED ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 19:54 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJВ приложении используются транзакции только такие, в которых TTransactionDesc.IsolationLevel = xilREADCOMMITTED В какие точно флаги Firebird это транслируется внутри драйвера? Ты трассировал транзакции, ты должен это знать. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 20:00 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 20:52 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Gallemar Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 21:18 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Вы просто ещё не поняли с кем связались. Он здесь любого перенудит влегкую, имхо.)) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 22:28 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Сомневаюсь. Во-первых, занудство плохо измеряемо. Во-вторых, на каждого зануду у нас есть Дима. P.S. Простите за занудство. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 22:40 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GallemarА надо всего лишь запустить трейс. Топикстартеры на такое обычно отвечают "запускал, не помогло". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 23:10 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJ YuRock пропущено... Не зна, при чем здесь "работать непосредственно с таблицами" или через процедуру. Ты, кажется, говорил, что UPDATE'ов этой таблицы - тысячи в разных местах. Упустил в моем сообщении еще один кусок текста: "А если разработать специальное клиентское приложение, то там пользователь даже открыть документ на редактирование не сможет, получит то самое сообщение, что документ пока занят". Приложения нашей системы так устроены, что пользователь просто не сможет открыть документ "на редактирование", если другой пользователь его уже открыл. Поэтому мне главное самому не напортачить с транзакциями, а никто посторонний помешать не сможет. Конечно же, за исключаем вмешательства грамотного человека с использованием IBExpert-а :) Но против лома нет приема. Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да). Там и еще были вопросы, но ты всё "упустил". ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 23:19 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Vlad F Вы просто ещё не поняли с кем связались. Он здесь любого перенудит влегкую, имхо.)) Лично я уже понял :) Кормить тролля больше не намерен. А порассуждать можно Во-первых, я не очень понимаю почему FB до сих пор с лёгкой руки Пресвятого Джима любой конфликт величает дедлоком. Ещё меньше я понимаю может ли движок опознать дедлок. И уж совсем не понимаю должен ли он этим заниматься. Мне каатся не его это движково дело. Во-вторых, если опустить головотяпство и разгильдяйство при управлении транзакциями, особенно стартуемыми и завершаемыми неестественным интеллектом, что действительно ставит гомосапиенса раком в затруднительные обстоятельства, а также перенасыщение бизнес-логикой триггеров и хранимок, то лок конфликт - это совершенно штатная ситуация в боле-мене сложных системах. И он не враг, а друг, так к нему и надо относиться и штатно обслуживать ситуации в которых он возникает. Вот представим себе, скажем, автобазу, у которой на сегодня осталась одна свободная машина. Трое менеджеров одновременно снимают трубки, реагируя на звонки клиентов, и начинается конкуренция за ресурс. В результате двое получают конфликт. Как его разрешать - не Железного Майка дело, это не алгоритмизируется. Коллеги, получив извещение о ситуёвине, должны возопить и промеж собой решить кому отдать предпочтение, потому что один из клиентов уж очень вонюч и темя проклюёт через начальство, другой постоянный партнёр, отпускать коего искать альтернативы, к которым он может уйти насовсем, нежелательно, а третий, который, вполне возможно, и оказался в очередушке первым, типа "мужик один приходил". Вопрос о том, в какой момент захватывать ресурс - при первом обращении к нему или завершающем мазке кистью - оставим в сторонке, это тема отдельного холивара, по которой всё что имел сказать, я сказал лет 15-20 назад. Или. О статусных полях. Ну какого лешего менеджеру работать с документом, если, пока он его разглядывал, Биг Босс поставил резолюцию - нах. Пусть при первом же телодвижении получит конфликт, перечитает данные, узрит резолюцию и расслабится. Есть ещё категория неизбежного зла. Приехал на склад вагон о 60 тоннах груза, например, дизайнерской полосато-волосатой бумаги из слонячьего говна, которую, в смысле каждую отдельную разновидность которой, сиречь номенклатурную позицию, оптовик берёт по две-три пачки на месяц. Весом по 2-3 кило пачка. Сколько там позиций в вагоне, считайте сами Грузчики носятся, кладовщик регистрирует состав складской операции приёмки, трали-вали-пассатижи. И вот наступает момент регистрации завершения операции. Тоиссь, пометки транспортной партии как неживой, увеличения складского запаса по всей этой туевой хуче номенклатурных позиций, отстрела в ценовые группы номенклатурных позиций количеств и цен для информирования коммерческого директора и прочих мыслящих группами, а не отдельными позициями, усреднения себестоимости по группам, изменения резервов на складе, в смысле под кого из потребителей что и сколько везли, снятие оных из транспортной партии и ещё чорта в ступе. Короче, текст ХП в максимальный размер блоба в системной таблице не влезает, приходится дробить. Дык оно ж минут 10 будет выполняться. На железе образца 5-го году. Не пугайтесь, не тыща девятьсот пятого. И за эти 10 минут чтоб другой кладовщик попытался зарегистрировать отгрузку одной пачки пусть даже не из присутствовавших в вагоне номенклатурных позиций, но входящих с ними в одну ценовую группу - да нефиг делать. И будет ему облом-с. В смысле Железный Майк раз 5 рестартует транзакцию и потыкается, а потом скажет - знаешь дорогой, занято. Пойди покури или там соточку накати и ущипни соседку-кладовщицу за жопу. А вот если он начал свою регистрацию отгрузки, в смысле транзакцию стартовал, раньше старта транзакции завершения приёмки, то это хуже, 10 минут превращаются в 20 если случилось сие на последней принимаемой позиции. Но деваться некуда. Умный человек это всё в приращениях делает, а не пишет в базу посчитанные за щекой новые значения, можно было бы и пропустить, но сервер не умеет оценивать IQ программиста и подходит к вопросу пессимистически. И правильно делает. Ситуация возникает нечасто, но необратимо, с этим надо примириться и обслуживать её. Чёта я раззвезделся на ночь глядя... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 00:41 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
YuRock Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да). Если с мудрствованиями лукавыми, то http://www.ibase.ru/pslock/ По-армейски коротко и ясно http://www.ibase.ru/plocks/ ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 00:52 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка 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.11.2021, 06:06 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
СПМ> Во-первых, я не очень понимаю почему FB СПМ> до сих пор любой конфликт величает дедлоком. Обратная совместимость, вероятно. Хотя с другой стороны, как водится, можно ввести соотв. переходный ключик и переименовывать. С третьей стороны, непонятно, нафига оно нужно... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 11:17 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov GJВ приложении используются транзакции только такие, в которых TTransactionDesc.IsolationLevel = xilREADCOMMITTED В какие точно флаги Firebird это транслируется внутри драйвера? Пардон за шаблонный ответ, но с какой целью интересуетесь? Это имеет какое-то отношение к теме, или просто поговорить? Так меня и так обвиняют в тоннах флуда. Если интересно, сооруди тестовую программу и посмотри. Gallemar Прошла неделя, мыши продолжают есть кактус. А надо всего лишь запустить трейс. Ну, наверное мышкам просто нравится здесь флудить общаться, потому что я открытым тестом уже давно сказал, что вопросов по теме больше не имею. Про сложности трейса в данном случае я уже упоминал. Десять баз, по 15 моих приложений на каждой. Плюс куча других приложений, работающих с той же базой. И прошла неделя, а ошибка еще не появилась. То есть всю эту неделю надо было с утра запускать трассировку на каждой БД. По уму, надо бы аудит настроить на серверах, но без админов заказчика этого не сделать. Vlad F Вы просто ещё не поняли с кем связались. Он здесь любого перенудит влегкую, имхо.)) Ты мне льстишь :) Судя по обсуждению, как минимум парочка участников мне ничуть не уступает. Или ты под занудством понимаешь спокойное ведение беседы, игнорируя многочисленные подъё... подколки и троллинг? :) Dimitry Sibiryakov Топикстартеры на такое обычно отвечают "запускал, не помогло". Уже обсуждалось, уже ответили. Мне посоветовали выполнить трассировку на локальной БД на своем компе, на что я ехидно ехидно ответил, что не помогло. А как оно могло помочь, если проблемы возникают только на базах заказчика. Причем, только одного заказчика?! YuRock Так я и спрашиваю, как же это оно так устроено? Через таблицу локов? С доп. транзакцией, или нет? (Хотя если говорит, каким пользователем занято, то да). Там и еще были вопросы, но ты всё "упустил". Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко. К данному обсуждению это все равно относится слабо, потому что приложение создает свой документ и проводит его до конца. С чужими документами не работает. Старый плюшевый мишка Лично я уже понял :) Кормить тролля больше не намерен. Написал человек и разродился огроменным постом по поводу блокировок при многопользовательской работе в теме, касающейся поиску ошибок в приложении, приводящих к возникновению блокировок при однопользовательской работе. Кажется, я перестаю понимать, что такое троллинг :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 23:10 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJПардон за шаблонный ответ, но с какой целью интересуетесь? Это имеет какое-то отношение к теме, или просто поговорить? Ещё раз, медленно: сабжевая ошибка может возникать в нескольких ситуациях: 1) update одной записи при всех уровнях изоляции. 2) select изменённой записи при уровне изоляции read committed no record version. 3) select for update. Во втором случае ты хоть затрассируйся update - ничего не найдёшь. GJМне посоветовали выполнить трассировку на локальной БД на своем компе, на что я ехидно ехидно ответил, что не помогло. А как оно могло помочь, если проблемы возникают только на базах заказчика. Причем, только одного заказчика?! Эта трассировка должна была выявить реальную последовательность работы приложения с БД и предоставить полный список изменяемых таблиц на которых способен происходить конфликт. Но не помогло так не помогло. Значит, не судьба. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 23:20 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJ Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко. К данному обсуждению это все равно относится слабо Тут тебе и лишние транзакции, которые можно забыть не открыть или закрыть, тут всё. Но если тебе не интересно - ок. Мне - тем более. Я заранее знаю, как оно у тебя устроено, просто тебя хотел на мысль навести, где проблему возможную искать. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 23:40 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJ Ну, наверное мышкам просто нравится здесь флудить общаться, потому что я открытым тестом уже давно сказал, что вопросов по теме больше не имею. Тогда имеет смысл прибить автора тему и разойтись ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2021, 09:00 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Gallemar, Погодите прибивать, можно просто ослабить давление. Он же должен в конце концов сообщить, чем там кончится дело.)) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2021, 10:44 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Эта трассировка должна была выявить реальную последовательность работы приложения с БД и предоставить полный список изменяемых таблиц на которых способен происходить конфликт. Эта последовательность работы может сильно различаться на разных базах, либо на одной базе, но разных кассах. либо на одной кассе, но разных товарах, либо... и так далее. Про это я уже говорил (пытался говорить) ранее. А что касается полного списка таблиц... передо мной стоит вполне конкретная задача, и я ее решаю. Доводить до совершенства все приложение я не возьмусь. YuRock GJ Если кратко, то принадлежность документа БД и таблица локов. Детальное же обсуждение будет здесь оффтопом. Если реально интересно, конечно, могу подготовиться и рассказать. Если для прикола, то лучше не надо. Толку все равно не будет, а времени жалко. К данному обсуждению это все равно относится слабо Тут тебе и лишние транзакции, которые можно забыть не открыть или закрыть, тут всё. Либо я не понял тебя, либо ты не понял меня. В БД существует специальная таблица, в которую заносится информация о том, что такой-то пользователь "открыл на редактирование такой-то документ" (в кавычках, потому что это условно-упрощенно, чтобы не вдаваться в детали). Соответственно, другое приложение не позволит открыть документ на редактирование, если он уже кем-то открыт. Таблица с содержательными данными при этом не блокируется, поэтому и говорю, что к обсуждаемому вопросу это отношения не имеет. Gallemar Тогда имеет смысл прибить автора тему и разойтись Ну... я, как бы, уже предлагал это. Не прибить, конечно, а просто закончить обсуждение. Но народ все пишет и пишет. Vlad F Gallemar, Погодите прибивать, можно просто ослабить давление. Он же должен в конце концов сообщить, чем там кончится дело.)) Ждать, скорее всего, придется долго. Я где-то через недельку выпадаю из общения (по медицинским аспектам) до нового года. Так что тема заглохнет сама собой и уползет вниз. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2021, 11:40 |
|
|
start [/forum/topic.php?fid=40&msg=40114720&tid=1559880]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
158ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 285ms |
0 / 0 |