#0
by Alex_MA
Здравствуйте! Помогите понять текущую картину. Управляемый режим: В ИТС статье написано, что дедлок такого типа возможен при чтении без установки блокировки и последующая запись - но как такое возможно. Ведь после чтения ресурса блокировка с него будет снята! Спасибо.
#0
by Alex_MA
Здравствуйте! Помогите понять текущую картину. Управляемый режим: В ИТС статье написано, что дедлок такого типа возможен при чтении без установки блокировки и последующая запись - но как такое возможно. Ведь после чтения ресурса блокировка с него будет снята! Спасибо.
#4
by DmitrO
Нет в платформе метода снять управляемую блокировку! Блокировки снимаются только завершением транзакции.
#5
by MrStomak
Дедлок по сценарию повышения уровня блокировки в упрявляемом режиме возможен только при установке разделяемой блокировки с последующей записью.
#8
by Alex_MA
вот и я так думаю. Для дедлока надо сначала заблокировать разделяемой, а потом повысить до исключительной
#9
by К_Дач
Если читаешь данные без установки блокировок - то по умолчанию режим чтения - read committed. При записи разработчик обязан в управляемом режиме сам управлять блокировками и уровнями изоляции. Соответственно, если запись набора записей регистра - это свойство БлокироватьДляИзменения (блокируется весь набор, блокировка снимается после записи набора), в остальных случаях - открывать транзакцию, блокировать нужные данные с помощью объекта БлокировкаДанных, закрывать транзакцию.
#11
by К_Дач
посмотри, что происходит в коде при одновременном чтении и записи. Кто-то из них пытается установить более пессимистичную блокировку
#12
by Господин ПЖ
>сценарию повышения уровня блокировки это вообще что? повышение уровня изоляции транзакций? изменение вида блокировки?
#13
by fisher
Да, странно... При READ COMMITED блокировка снимается сразу после чтения... А как статья называется?
#14
by DmitrO
"повышение уровня блокировки" это с разделяемой до исключительной. Лочит твоя транзакция сначала разделяемой потом исключительной один и тот же объект. говоришь "без Новый БлокировкаДанных" как читаешь? а)запросом? или б)объект получаешь или набор записей читаешь?
#16
by DmitrO
Просто где-то в последних релизах 8.2 умники в 1С решили, что если объект читается в транзакции то непременно надо воткнуть разделяемую блокировку (внутренее).
#18
by Alex_MA
только если в коде написано Новый БлокировкаДанных - то уже да, до конца транзакции. А если не написано, то не лочится
#21
by MrStomak
Перевести с разделяемой на исключительную блокировку - это повысить уровень блокировки. Т.е. нам нужно усилить имеющуюся блокировку, увеличить количество конфликтов в таблице совместимостей. На мой взгляд, это достаточно понятный термин.
#25
by fisher
Для управляемого режима написано следующее: "Обратите внимание на то, что взаимоблокировки в данном случае не произошло. Вместо этого была нарушена бизнес-логика системы"
#27
by MrStomak
Менеджер блокировок работает над СУБД, у него нет информации о данных, он не может знать, что запрос нам вернёт и что он пройдёт по пути, автоматическая блокировка при чтении средствами менеджера 1С невозможна. При записи используется объектная техника и всегда есть конкретные записываемые данные - вот тут менеджер блокировок может автоматически выставить исключительную блокировку.
#29
by DmitrO
Я не говорил ничего про автоматические блокировки. Я имел в виду что будет вставать разделяемая управляемая. Полностью согласен с . Хотя вот я уже специально проверил на 8.2.19.83 - нет ее. Хм.. тогда о чем же мы говорили с Рупасовым.. склероз у меня чтоли, старость не радость.. сори кого обидел..
#30
by fisher
Чисто теоретически, могли повысить уровень изоляции до REPEATABLE READ. Тогда прочитанные данные будут блокироваться до конца транзакции. Но это нонсенс. Думаю, просто не поняли друг-друга.
#31
by К_Дач
, друзья, я знаю, что по факту это включение/выключение разделения итогов "следствием этого является блокировка всех нужных записей (без учета разделителя)" = "блокируется весь набор, блокировка снимается после записи набора"
#32
by MrStomak
Да ты в общем неверно пишешь, при записи разработчик ничего не должен делать как раз - управляемая блокировка при записи встаёт самостоятельно. То, что блокировка снимается после записи, тоже неверно - она снимается при окончании транзакции.
#33
by К_Дач
Блокировка снимается после окончания транзакции - абсолютно верно, а когда заканчивается транзакция в случае записи набора записей регистра? Как раз таки именно разработчик должен позаботиться о том, чтобы грамотно наложить нужные блокировки на нужные данные при их записи. Возможно ли чтение этих данных в процессе записи или невозможно. Какой уровень изоляции выставить и т.д., какие конкретно данные блокировать - это все на совести того, кто непосредственно внедряет многопользовательскую систему.
#35
by К_Дач
В автоматическом режиме работы - блокируется вся таблица, куда пишутся данные, многопользовательская работа невозможна. В управляемом - разработчик сам обязан все проконтролировать, вот что имел ввиду. Надо смотреть в коде чтения и записи, что там происходит, может чтение пытается выставить исключительную блокировку
#36
by DmitrO
К_Дач, как давно ты занимаешься "непосредственным внедрением многопользовательских систем"?
#37
by MrStomak
Запись набора записей не заканчивает транзакцию. Например, там может быть запись следующего набора записей потом. Если речь про операцию .Записать, находясь вне транзакции, то тогда безусловно - она закончится после записи, но и смысла в каких-либо управляемых блокировках в таком случае нет. Разработчик не должен заботиться о наложении блокировок при записи на записываемые данные, они и сами накладываются прекрасно. Разработчику следует чесаться только тогда, когда ему по какой-либо причине нужно наложить более широкую блокировку, чем просто на записываемые данные. Например, в упомянутом тобой случае с разделителем. Разработчик не выставляет уровни изоляции транзакций. Всё его манипулирование уровнями изоляций сводится к выставлению автоматическиго/управляемого режима (serializable-repeatableread/readcommitted), а также использованию или не использованию НачатьТранзакцию при чтении данных (readuncommitted или repeatableread-readcommitted). В автоматическом режиме вся таблица блокируется только при использовании СУБД-версионников и файлового варианта (который тоже версионник).
#38
by К_Дач
как раз сейчас внедряем. Одновременная запись и чтение из разных БД в одну и ту же таблицу и не стандартными средствами платформы 1С, между прочим, хотя и из нее. Вместо того, чтобы переходить на личности, если не согласны опровергните аргументированно. Вводная: Необходимо, чтобы в одну и ту же таблицу писались одновременно данные. Одинаковый набор всех полей-колонок возможен. Необходимо реализовать, чтобы записываемые данные не читались до тех пор, пока не запишется весь пакет строк. Необходимо, чтобы чтение данных не мешало записи и не замедляло ее работу. Запись не должна ждать чтение. Как будете реализовывать?
#39
by Alex_MA
в абзаце: "Особенности взаимоблокировок данного вида" Автоматический режим: .... Управляемый режим
#41
by MrStomak
1) версионная схема с read committed. 2) использовать 2 БД, зеркалировать 1 во 2, выставлять для 2ой read-only. Пункт с замедлением работы неясен - ресурсы СУБД не бесконечны, любая операция влияет.
#43
by К_Дач
запись набора производится в СВОЕЙ, отдельной транзакции, во вложенной. Легко проверить, если в документе, проводимом по нескольким регистрам в одном из регистров выставить автоматический режим - вывалится ошибка.
#44
by MrStomak
Я даже не знаю как это комментировать, чтобы не обидеть. Ну посмотрите профайлером начало и конец транзакции. Или попробуйте откатить только запись регистра, продолжая проведение документа. Или посмотрите блокировки в sp_locks после того, как все регистры записаны. Можно еще почитать ИТС.
#47
by К_Дач
, а судьи кто? ;) профайлером не проверял. Режим проведения документа - управляемый. Режим одного из регистров, непосредственно по которому документ не проводится - автоматический. В итоге: Ошибка при выполнении обработчика - 'ПриЗаписи'. Ошибка использования Менеджера блокировок Автоматический режим блокировки недопустим в этой транзакции. Столкнувшись раз с такой ошибкой, решил, что запись наборов делается во вложенных транзакциях. Ошибаюсь?
#48
by К_Дач
На минуточку, мы тут выяснили выше, что блокировки выставляет и снимает открываемая транзакция. 10 регистров, все в управляемом, один в автоматическом. И?
#49
by К_Дач
Если документ проводится в упр режиме, транзакция открыта в управляемом режиме, явно или нет. Так почему же он тогда не игнорирует свойство регистра? И зачем тогда вообще это свойство, если можно было бы обойтись только свойством документа? Эй, "знатоки" , , поделитесь соображениями
#51
by DmitrO
Об этом написано в документации. Читать пробовали? Для этого не надо быть "знатоком". Читать, только читать, писать еще рано.
#52
by fisher
Какими соображениями? Это тупо проверка платформы на совместимость режимов. Остальное - твои домыслы.
#53
by К_Дач
ну так дай ссылку, ткни так сказать носом нерадивого, а уж потом только взывай к всевышнему. Я если не прав - признаю и скажу спасибо, что наставил на путь истинный, а пока так - типа ты, холоп, недостоин еще с барином спор вести. Несолидно
#55
by fisher
Эта загадочная фраза должна была что-то прояснить? В любом случае, мне это неинтересно.
#56
by DmitrO
да я и ссылку могу дать: Если туда нет доступа, то это: Руководство программиста 9.3.5
#57
by К_Дач
я предполагаю, что записи наборов регистров производятся во вложенных транзакциях. На этот вывод меня натолкнула ситуация из , а также статья: Господа , и изволили посмеяться, однако контраргументов не привели.
#58
by DmitrO
А еще небольшой раздел 9.2.2 вам будет очень полезен. :) Чтобы вы не пугали своих заказчиков "вложенными" транзакциями, они ведь тоже могут оказаться людьми грамотными.
#59
by К_Дач
О, ну да, "вложенный" - конечно не то слово, которое верно отражает суть, но для простого понимания, "на пальцах" - почему бы и нет, спасибо, месье Прокомментируй таблицу №3 из статьи в , там где " Сочетания режимов управления блокировками в транзакции"
#60
by MrStomak
Какие тут могут быть "аргументы"? Берешь и проверяешь. Есть ТЖ, есть профайлер, раздолье для любых проверок. Лениво тебе что-то объяснять, ты явно не стремишься к пониманию. Зато не стесняешься писать откровенный бред про снятие блокировок после записей регистров, ручные блокировки при записи объектов, управление уровнями изоляций и так далее.
#61
by К_Дач
последняя попытка вступить в конструктивный спор. 1. "снятие блокировок после записей регистров" - я уверен, что блокировки устанавливаются и снимаются транзакцией, в рамках которой производится запись набора. Также считаю, что набор записывается в рамках отдельной транзакции (раздел 9.3.5, ситуация из ),слово "вложенный" применять не буду, хотя на ИТС спокойно оперируют понятием "транзакция верхнего уровня". Но, думаю, понятно, о чем идет речь. Запись набора заканчивается фиксацией транзакции, поэтому "снятие блокировок после записей регистров". 2. "ручные блокировки при записи объектов, управление уровнями изоляций" - я попытался озвучить общий принцип, чтобы обратить внимание автора, где искать решение проблемы, на возможную коллизию чтения и записи или параллельной записи. Верность этих утверждений могу подтвердить практическим примером: при работе напрямую с СУБД, необходимо явно указывать уровень изоляции транзакции и блокировки. У объекта ADO, для наглядности, для этого есть свойства IsolationLevel и LockType. Кажется, аргументировано? Опровергните или укажите на ошибки.
#62
by К_Дач
вы сами, в проверяли где и как открываются и фиксируются транзакции при проведении документа по нескольким регистрам? или голословно?
#63
by fisher
Нет чтобы сказать - простите дурака, у меня в голове каша из транзакций СУБД и транзакций 1С. Нужно права качать.
#64
by MrStomak
1. Друг, фразы вроде "я уверен" не имеют никакого отношения к "конструктивному спору". Тебе предложено проверить - ты отказываешься. Выдержка из документации, надеюсь, достаточно конструктивна: "Это означает, что всегда действует только транзакция самого верхнего уровня. Все транзакции, вызванные внутри уже открытой транзакции, фактически относятся к той же транзакции, а не образуют вложенную транзакцию" 2. А управляемый и автоматический режимы, про который ты при этом пишешь, они в каком свойстве объекта ADO находятся? Я смотрел километры логов ТЖ.
#65
by К_Дач
никто ничего не качает, лично я пытаюсь разобраться. Проверять тоже не отказывался, разве где-то написал об этом? с удовольствием проверю, благо и задачи как раз по теме.
#66
by fisher
Самое смешное, что мне неясно, каким бы образом повлияло использование вложенных транзакций СУБД (если бы они имели место) на профильное обсуждение.
#67
by К_Дач
Хорошо, тогда кто-нибудь, объясните, почему возникает ситуация в ? Еще раз, режим работы конфигурации - автоматический и управляемый. Документ проводится, записывается и удаляется в управляемом режиме. Один из регистров - в автоматическом. Транзакция по документу открыта в управляемом режиме, одна из транзакций по регистру пытается открыться в автоматическом до момент фиксации "самой первой" (давайте так говорить) транзакции - ошибка. Выходит, все-таки набор записывается в своей транзакции, разве нет? Да, она в рамках "самой первой", но тем не менее?
#68
by fisher
Нет. Признак режима блокировок для регистра - это всего лишь контролька. Признак. Галка. Чтобы исключить запись в одну и ту же таблицу с использованием разных идеологий блокировок.
#69
by MrStomak
Вся эта ситуация - конкретный способ реализации смешанного режима блокировок в 1с. В автоматическом режиме у нас просто идут запросы в СУБД, это более простой для платформы режим. В управляемом используется новый элементв уравнении - менеджер блокировок 1с. В смешанном режиме, чтобы менеджер блокировок мог установить управляемую блокировку, объект блокировки должен поддерживать работу в управляемом режиме - то есть в метаданных это явно должно быть прописано, так вот решили сделать. Почему управляемый в автоматическом может работать,а наоборот - нет? Так это как раз следствие того, что всё происходит в одной транзакции! Если у транзакции автоматический режим, значит она менеджер блокировок использовать не будет в любом случае - ей не важно, что там будет у остальных объектов стоять в качестве режима блокировки. Если у транзакции управляемый режим, то запись любого объекта будет вызывать помимо всего прочего еще и попытку наложения управляемой блокировки. А для регистров в автоматическом режиме это сделать будет нельзя - это запрещено разработчиком в конфигураторе!
#70
by fisher
Не совсем так. Намутили они со смешанным режимом чего-то. Мне крышу сносит этот абзац из документации: "Первая особенность заключается в том, что даже если для транзакции используется автоматический режим управления блокировками, система установит дополнительно и соответствующие управляемые блокировки при записи данных в этой транзакции. Из этого следует, что транзакции, исполняющиеся в режиме управляемых блокировок, могут конфликтовать с транзакциями, исполняющимися в режиме автоматического управления блокировками." Вот что они имели в виду? Что такое "соответствующие управляемые блокировки"?
#71
by MrStomak
Имеют ввиду, что при записи регистра на всякий случае будет установлена управляемая исключительная блокировка, как если бы он записывался в управляемой транзакции. Уровень изоляции транзакций на СУБД при этом всё равно остаётся высоким, а нужно это для того, чтобы управляемые блокировки на регистр не игнорировались при его записи из автоматической транзакции.
#72
by fisher
На какой "всякий" случай? Для параллельной управляемой транзакции? А нафига? Что-то я туплю под конец дня...
#73
by MM
Пример, регистр в управляемом режиме, его двигают два документа один в управляемой транзакции, второй в автоматической. Как его предложите блокировать на СУБД или в менеджере блокировок 1С? Совместимость штука мутная.
#74
by fisher
Автоматическая транзакция в любом случае на уровне СУБД заблокирует те же ресурсы, что и "дублированной" управляемой блокировкой. При этом "дубляж" ничего не решает, т.к. автоматическая блокировка всегда будет "попутно" блокировать и другие ресурсы, о которых менеджер управляемых блокировок заведомо ничего знать не будет.
#75
by MM
Раз не знает значит они и не важны. Продолжая оба документа прочли регистр, первый поставил управляемую блокировку (на СУБД поставил и снял); второй накладывает S (или U) на остатки регистра. Потом первый документ хочет писать и ждёт снятия на уровне СУБД; второй повышает S (или U) до X, пишет и успешно заканчивает транзакцию. Первый документ списывает в минус на разлоченном регистре.
#76
by MrStomak
Автоматическая блокировка ничего не будет знать о ручной управляемой блокировке в соседней, управляемой, транзакции, и позволит записать документ тогда, когда разработчик явно это запретил.
#77
by К_Дач
, если я все верно понимаю, по одним и тем же регистрам не должны делать движения документы в разных режимах....? зачем тогда режим совместимости... Вернее тогда всю конфигурацию перевести в управляемый режим.
#78
by MM
неверно. В смешанном режиме автоматический режим транзакции ставит некоторые управляемые блокировки сам. + процесс перехода подразумевает установку управляемых блокировок из кода даже в автоматическом режиме транзакции, с заделом на будущее, когда они понадобятся. Т.е. если хочешь сделать регистр управляемым, везде где надо, ставь управляемые блокировки, а затем меняй его режим. Когда закончишь эту операции со всеми регистрами по которым проводится документ, можно и документ сделать управляемым. И так далее. Мне тоже кажется, что всю конфигурацию проще перевести в управляемый режим сразу.
#79
by kuromanlich
" режим транзакции ставит некоторые управляемые блокировки сам" - наверное "позволяет ставить"
#80
by vi0
> В автоматическом режиме вся таблица блокируется только при использовании СУБД-версионников можно этот момент поподробнее интересно исходя из того, что блокировок в версионнике наоборот становится меньше, насколько я могу судить по sql server
#81
by vi0
+ так, это у нас в управляемом режиме так работает а что тогда под версионником здесь подразумеваешь?
#82
by Новиков
Чувствую, в этой ветке порвется еще много валькин-дед-bоянов. В любом случае, прав, впрочем как и всегда ;)
#83
by vi0
+ Вижу в документации, что при автоматическом режиме у Постгреса и Оракла блокируются таблицы. Я правильно понимаю, что это 1С их так ограниченно использует, что Оракл аналогичен файловой БД по способу блокирования?
#84
by MrStomak
Я думаю, это связано с особенностями блокировок у версионников на высоких уровнях изоляции. Вот выдержка из документации на PostgreSQL пункт 13.3.2: Row-level locks do not affect data querying; they block only writers to the same row.
#87
by su_mai
Речь идет о транзакционных блокировках, действующих до окончания транзакции, в которой они вызваны.
#91
by vi0
я к тому, что 1с юзает крутой оракл как файловую базу и причина тут только в 1с, а не в оракле вопрос в этом был
#92
by MM
Причина в том, что автоматический режим не должен применяться с версионными СУБД, включая оракл. Он существует для совместимости со старыми конфигурациями.
#93
by MrStomak
Я не очень понимаю выражения "юзать как файловую базу". Да, процедуры, триггеры, функции, пакеты не используются. Равно как и не используются возможности любой другой СУБД, работающей с 1С. Всё многообразие типов данных, объектов - всё мимо. Но связано всё это с тем, что прикладная логика зашивается в конфигурации и платформе и нет смысла переносить её в СУБД, которая решает только задачи чтения/записи. Иначе невозможно было бы поддерживать работу платформы на разных СУБД.
#94
by vi0
это да я о другом - о твоей фразе > В автоматическом режиме вся таблица блокируется только при использовании СУБД-версионников
#95
by vi0
> автоматический режим не должен применяться с версионными СУБД это официальная информация?
#96
by fisher
, Я просил пример коллизий для случая, когда автоматический режим НЕ УСТАНАВЛИВАЕТ управляемые блокировки, а не когда он их НЕ ПРОВЕРЯЕТ. Ясен пень, что раз допускается совместное использование управляемых и автоматических блокировок, то транзакции в автоматическом режиме должны анализировать управляемые блокировки. Непонятно, нафига в автоматическом режиме УСТАНАВЛИВАТЬ управляемые блокировки.
#97
by MrStomak
"то транзакции в автоматическом режиме должны анализировать управляемые блокировки" Такой операции как "анализировать" не существует в прикладном решении. "Анализом" по таблице совместимости занимается менеджер блокировок СУБД и менеджер блокировок 1С, когда в них пытаются засунуть новую блокировку. В случае, если в менеджер блокировок 1С устанавливать блокировку не будут, то и никого "анализа" не последует. СУБД скажет "на блокировку, всё ок" и будет лажа.
Тэги: 1С 8
Ответить:
Комментарии доступны только авторизированным пользователям
Похожие вопросы 1С
- Помогите, надо приказ на повышение окладов сотрудникам
- Как в ЗуП отразить повышение окладов по предприятию
- Deadlock (sql state 40001 native 1205)
- Снова PostgreSQL 8.4.3-3.1C + 1С 8.2 "deadlock detected" помогите с настройками
- v7: Ошибка блокировки данных на SQL сервере (deadlock)
- Привилегированный режим и режим запуска приложения - какая связь?
- READ_COMMITTED_SNAPSHOT и автоматический режим блокировки данных
- Условное оформление для уровня в динамическом списке
В этой группе 1С
- Выгрузка проводок из зик 7.7 в бп 3.0. Не переносятся подразделения!
- Зуп: Временно пребывающие иностранцы не попадают в РСВ1
- SuperMicro или HUAWEI?
- Не появляется кнопка Печать. УФ
- v7: ЗиК недоразвит в части учета классов условий труда?
- Учет суммы накоплений в еще не пробитом чеке
- УТ11 Возврат товаров поставщику
- 1С БП 3 - УТ 11 - обмен данными - проблема
- обмен упп - упп
- Обработка внешнего события в документе ЧекККМ Розница 2.1
- 1С 8.2 хранение большого количества записей - Справочник vs Регистр сведений
- Сторонний Web сервис
- Задваивает показатели в отчете "Расчет среднегодовой стоимости имущества"
- БП 3.0 не могу вывести дополнительный реквизит на форму списка
- Производительность запроса Карточки Счет (УПП 1.3)
- Обработка выбора в управляемой форме
- Режим разделения итогов увеличивает таблицу оборотов вдвое?
- Обмен в фоновом режиме: файловая база данных
- Как из 1с залогиниться на сайт и считать данные со страницы?
- Регистр сведений: записи с такими ключ.полями уже существуют