Здравствуйте!

Помогите понять текущую картину.
Управляемый режим:
В ИТС статье написано, что дедлок такого типа возможен при чтении без установки блокировки и последующая запись - но как такое возможно. Ведь после чтения ресурса блокировка с него будет снята!

Спасибо.

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

(8) управляемый режим не всегда был в 1С

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

>сценарию повышения уровня блокировки

это вообще что? повышение уровня изоляции транзакций? изменение вида блокировки?

(0) Да, странно... При READ COMMITED блокировка снимается сразу после чтения... А как статья называется?

(0) "повышение уровня блокировки" это с разделяемой до исключительной.
Лочит твоя транзакция сначала разделяемой потом исключительной один и тот же объект.
говоришь "без Новый БлокировкаДанных"
как читаешь? а)запросом? или б)объект получаешь или набор записей читаешь?

(13) в СУБД - да, а в менеджере блокировок 1С будет висеть до конца транзакции

Просто где-то в последних релизах 8.2 умники в 1С решили, что если объект читается в транзакции то непременно надо воткнуть  разделяемую блокировку (внутренее).

(13)"Анализ и устранение взаимоблокировок"

(15)только если в коде написано Новый БлокировкаДанных - то уже да, до конца транзакции. А если не написано, то не лочится

(9) У вас неверное представление о назначении свойства "БлокироватьДляИзменения"

(16) Это же неправда. Зачем так писать?

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

(9)
http://wwind.ua/documents/index.php?ELEMENT_ID=453#main_tesis
http://infostart.ru/public/196565/

(17) Не вижу я там такого для управляемых блокировок. Конкретизируй место в статье.

(20)лично слышал это, от чего сам был в недоумении.

(23) Для управляемого режима написано следующее:
"Обратите внимание на то, что взаимоблокировки в данном случае не произошло. Вместо этого была нарушена бизнес-логика системы"

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

(24) Менеджер блокировок работает над СУБД, у него нет информации о данных, он не может знать, что запрос нам вернёт и что он пройдёт по пути, автоматическая блокировка при чтении средствами менеджера 1С невозможна. При записи используется объектная техника и всегда есть конкретные записываемые данные - вот тут менеджер блокировок может автоматически выставить исключительную блокировку.

(24) Плюнь в сказавшего
(27) +1

(27)Я не говорил ничего про автоматические блокировки. Я имел в виду что будет вставать разделяемая управляемая.
Полностью согласен с (27).

Хотя вот я уже специально проверил на 8.2.19.83 - нет ее.
Хм.. тогда о чем же мы говорили с Рупасовым.. склероз у меня чтоли, старость не радость..
сори кого обидел..

(29) Чисто теоретически, могли повысить уровень изоляции до REPEATABLE READ. Тогда прочитанные данные будут блокироваться до конца транзакции. Но это нонсенс.
Думаю, просто не поняли друг-друга.

(19), (22) друзья, я знаю, что по факту это включение/выключение разделения итогов

"следствием этого является блокировка всех нужных записей (без учета разделителя)" = "блокируется весь набор, блокировка снимается после записи набора"

(31) Да ты в общем неверно пишешь, при записи разработчик ничего не должен делать как раз - управляемая блокировка при записи встаёт самостоятельно. То, что блокировка снимается после записи, тоже неверно - она снимается при окончании транзакции.

(31) Блокировка снимается после окончания транзакции - абсолютно верно, а когда заканчивается транзакция в случае записи набора записей регистра?

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

(33) к (32)

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

К_Дач, как давно ты занимаешься "непосредственным внедрением многопользовательских систем"?

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

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

Разработчик не выставляет уровни изоляции транзакций. Всё его манипулирование уровнями изоляций сводится к выставлению автоматическиго/управляемого режима (serializable-repeatableread/readcommitted), а также использованию или не использованию НачатьТранзакцию() при чтении данных (readuncommitted или repeatableread-readcommitted).

В автоматическом режиме вся таблица блокируется только при использовании СУБД-версионников и файлового варианта (который тоже версионник).

(36) как раз сейчас внедряем. Одновременная запись и чтение из разных БД в одну и ту же таблицу и не стандартными средствами платформы 1С, между прочим, хотя и из нее.

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

Вводная:

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

Как будете реализовывать?

(25)в абзаце:
"Особенности взаимоблокировок данного вида"

Автоматический режим:
....
Управляемый режим

(38)Это был просто вопрос, не напрягайтесь так. Буду считать что вы на него ответили. :)

(38) 1) версионная схема с read committed.
     2) использовать 2 БД, зеркалировать 1 во 2, выставлять для 2ой read-only.

Пункт с замедлением работы неясен - ресурсы СУБД не бесконечны, любая операция влияет.

(39) Ага. А переходишь по ссылке "Управляемый режим", а там (25)

(33) запись набора производится в СВОЕЙ, отдельной транзакции, во вложенной. Легко проверить, если в документе, проводимом по нескольким регистрам в одном из регистров выставить автоматический режим - вывалится ошибка.

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

господь всемогущий, прости их, ибо они не ведают что творят :)

(43) Нобелевская. Продолжай наблюдения.

(45), (46) а судьи кто? ;)

(43) профайлером не проверял.

Режим проведения документа - управляемый. Режим одного из регистров, непосредственно по которому документ не проводится - автоматический. В итоге:

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

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

На минуточку, мы тут выяснили выше, что блокировки выставляет и снимает открываемая транзакция. 10 регистров, все в управляемом, один в автоматическом. И?

Если документ проводится в упр режиме, транзакция открыта в управляемом режиме, явно или нет. Так почему же он тогда не игнорирует свойство регистра? И зачем тогда вообще это свойство, если можно было бы обойтись только свойством документа? Эй, "знатоки" (45), (46), поделитесь соображениями

(42)Ага. Вообщем статья криво написана. Вводит в заблуждение.

(49)Об этом написано в документации. Читать пробовали? Для этого не надо быть "знатоком".
Читать, только читать, писать еще рано.

(49) Какими соображениями? Это тупо проверка платформы на совместимость режимов. Остальное - твои домыслы.

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

(52) тут выше писали, что, мол уровнями блокировок управляет транзакция

(54) Эта загадочная фраза должна была что-то прояснить? В любом случае, мне это неинтересно.

(53)да я и ссылку могу дать: http://its.1c.ru/db/v8doc#content:63:1:IssOgl2_9.3.5.ОсобенностиработыврежимеАвтоматическийиуправляемый

Если туда нет доступа, то это: Руководство программиста 9.3.5

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

http://www.lavelin.ru/articles/18-1s/razrabotka-i-administrirovanie/268-blokirovki-dannyh-v-1spredpriyatii-8.html

Господа (44), (45) и (46) изволили посмеяться, однако контраргументов не привели.

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

(58) О, ну да, "вложенный" - конечно не то слово, которое верно отражает суть, но для простого понимания, "на пальцах" - почему бы и нет, спасибо, месье

Прокомментируй таблицу №3 из статьи в (57), там где " Сочетания режимов управления блокировками в транзакции"

(57) Какие тут могут быть "аргументы"? Берешь и проверяешь. Есть ТЖ, есть профайлер, раздолье для любых проверок.

Лениво тебе что-то объяснять, ты явно не стремишься к пониманию.

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

(60) последняя попытка вступить в конструктивный спор.

1. "снятие блокировок после записей регистров" - я уверен, что блокировки устанавливаются и снимаются транзакцией, в рамках которой производится запись набора. Также считаю, что набор записывается в рамках отдельной транзакции (раздел 9.3.5, ситуация из (47)),слово "вложенный" применять не буду, хотя на ИТС спокойно оперируют понятием "транзакция верхнего уровня". Но, думаю, понятно, о чем идет речь. Запись набора заканчивается фиксацией транзакции, поэтому "снятие блокировок после записей регистров".

2. "ручные блокировки при записи объектов, управление уровнями изоляций" - я попытался озвучить общий принцип, чтобы обратить внимание автора, где искать решение проблемы, на возможную коллизию чтения и записи или параллельной записи. Верность этих утверждений могу подтвердить практическим примером: при работе напрямую с СУБД, необходимо явно указывать уровень изоляции транзакции и блокировки. У объекта ADO, для наглядности, для этого есть свойства IsolationLevel и LockType.

Кажется, аргументировано? Опровергните или укажите на ошибки.

(60) вы сами, в (44) проверяли где и как открываются и фиксируются транзакции при проведении документа по нескольким регистрам? или голословно?

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

(61)
1. Друг, фразы вроде "я уверен" не имеют никакого отношения к "конструктивному спору". Тебе предложено проверить - ты отказываешься.
Выдержка из документации, надеюсь, достаточно конструктивна: "Это означает, что всегда действует только транзакция самого верхнего уровня. Все транзакции, вызванные внутри уже открытой транзакции, фактически относятся к той же транзакции, а не образуют вложенную транзакцию"
2. А управляемый и автоматический режимы, про который ты при этом пишешь, они в каком свойстве объекта ADO находятся?
(62) Я смотрел километры логов ТЖ.

(63) никто ничего не качает, лично я пытаюсь разобраться. Проверять тоже не отказывался, разве где-то написал об этом? с удовольствием проверю, благо и задачи как раз по теме.

Самое смешное, что мне неясно, каким бы образом повлияло использование вложенных транзакций СУБД (если бы они имели место) на профильное обсуждение.

Хорошо, тогда кто-нибудь, объясните, почему возникает ситуация в (47)? Еще раз, режим работы конфигурации - автоматический и управляемый. Документ проводится, записывается и удаляется в управляемом режиме. Один из регистров - в автоматическом. Транзакция по документу открыта в управляемом режиме, одна из транзакций по регистру пытается открыться в автоматическом до момент фиксации "самой первой" (давайте так говорить) транзакции - ошибка. Выходит, все-таки набор записывается в своей транзакции, разве нет? Да, она в рамках "самой первой", но тем не менее?

(67) Нет. Признак режима блокировок для регистра - это всего лишь контролька. Признак. Галка. Чтобы исключить запись в одну и ту же таблицу с использованием разных идеологий блокировок.

(67) Вся эта ситуация - конкретный способ реализации смешанного режима блокировок в 1с. В автоматическом режиме у нас просто идут запросы в СУБД, это более простой для платформы режим. В управляемом используется новый элементв  уравнении - менеджер блокировок 1с. В смешанном режиме, чтобы менеджер блокировок мог установить управляемую блокировку, объект блокировки должен поддерживать работу в управляемом режиме - то есть в метаданных это явно должно быть прописано, так вот решили сделать. Почему управляемый в автоматическом может работать,а  наоборот - нет? Так это как раз следствие того, что всё происходит в одной транзакции! Если у транзакции автоматический режим, значит она менеджер блокировок использовать не будет в любом случае - ей не важно, что там будет у остальных объектов стоять в качестве режима блокировки. Если у транзакции управляемый режим, то запись любого объекта будет вызывать помимо всего прочего еще и попытку наложения управляемой блокировки. А для регистров в автоматическом режиме это сделать будет нельзя - это запрещено разработчиком в конфигураторе!

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

(70) Имеют ввиду, что при записи регистра на всякий случае будет установлена управляемая исключительная блокировка, как если бы он записывался в управляемой транзакции. Уровень изоляции транзакций на СУБД при этом всё равно остаётся высоким, а нужно это для того, чтобы управляемые блокировки на регистр не игнорировались при его записи из автоматической транзакции.

(71) На какой "всякий" случай? Для параллельной управляемой транзакции? А нафига? Что-то я туплю под конец дня...

(72) Пример, регистр в управляемом режиме, его двигают два документа один в управляемой транзакции, второй в автоматической. Как его предложите блокировать на СУБД или в менеджере блокировок 1С?
Совместимость штука мутная.

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

(74) Раз не знает значит они и не важны.
Продолжая (73) оба документа прочли регистр, первый поставил управляемую блокировку (на СУБД поставил и снял); второй накладывает S (или U) на остатки регистра.
Потом первый документ хочет писать и ждёт снятия на уровне СУБД; второй повышает S (или U) до X, пишет и успешно заканчивает транзакцию.
Первый документ списывает в минус на разлоченном регистре.

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

(75), (76) если я все верно понимаю, по одним и тем же регистрам не должны делать движения документы в разных режимах....? зачем тогда режим совместимости... Вернее тогда всю конфигурацию перевести в управляемый режим.

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

(78) " режим транзакции ставит некоторые управляемые блокировки сам" - наверное "позволяет ставить"

(37)
> В автоматическом режиме вся таблица блокируется только при использовании СУБД-версионников

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

+(80) так, это у нас в управляемом режиме так работает
а что тогда под версионником здесь подразумеваешь?

Чувствую, в этой ветке порвется еще много валькин-дед-bоянов.

В любом случае, MrStomak прав, впрочем как и всегда ;)

+(80) Вижу в документации, что  при автоматическом режиме у Постгреса и Оракла блокируются таблицы.

Я правильно понимаю, что это 1С их так ограниченно использует, что Оракл аналогичен файловой БД по способу блокирования?

http://its.1c.ru/db/v83doc#content:67:1:IssOgl2_9.3.2.Управляемыеблокировки

(83) Я думаю, это связано с особенностями блокировок у версионников на высоких уровнях изоляции. Вот выдержка из документации на PostgreSQL пункт 13.3.2: Row-level locks do not affect data querying; they block only writers to the same row.

(79) Да нет, именно ставит...

(82) Чувствую, где не отпишу - ты тут как тут, караулишь, контролируешь :)

(0) Речь идет о транзакционных блокировках, действующих до окончания транзакции, в которой они вызваны.

+(87) SQL Server Profiler Вам в помошь :)
или на крайняк, технологический журнал.

(84) А какие блокировки у версионников?

(84) Тут файерберд пытался блокировать, а меня спрашивают - "а что такое блокировка?"

(84) я к тому, что 1с юзает крутой оракл как файловую базу
и причина тут только в 1с, а не в оракле
вопрос в этом был

(91) Причина в том, что автоматический режим не должен применяться с версионными СУБД, включая оракл. Он существует для совместимости со старыми конфигурациями.

(91) Я не очень понимаю выражения "юзать как файловую базу". Да, процедуры, триггеры, функции, пакеты не используются. Равно как и не используются возможности любой другой СУБД, работающей с 1С.
Всё многообразие типов данных, объектов - всё мимо.
Но связано всё это с тем, что прикладная логика зашивается в конфигурации и платформе и нет смысла переносить её в СУБД, которая решает только задачи чтения/записи. Иначе невозможно было бы поддерживать работу платформы на разных СУБД.

(93) это да
я о другом - о твоей фразе
> В автоматическом режиме вся таблица блокируется только при использовании СУБД-версионников

(92)
> автоматический режим не должен применяться с версионными СУБД
это официальная информация?

(75),(76) Я просил пример коллизий для случая, когда автоматический режим НЕ УСТАНАВЛИВАЕТ управляемые блокировки, а не когда он их НЕ ПРОВЕРЯЕТ. Ясен пень, что раз допускается совместное использование управляемых и автоматических блокировок, то транзакции в автоматическом режиме должны анализировать управляемые блокировки. Непонятно, нафига в автоматическом режиме УСТАНАВЛИВАТЬ управляемые блокировки.

(96) "то транзакции в автоматическом режиме должны анализировать управляемые блокировки"

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

В случае, если в менеджер блокировок 1С устанавливать блокировку не будут, то и никого "анализа" не последует. СУБД скажет "на блокировку, всё ок" и будет лажа.

(97) Таки да, тупанул. Спасибо.

(93) можно было хотя бы часть реализовать через хранимые процедуры, в 7.7 же они использовались иногда
(95) прямое следствие из факта (91)

(99) ну как логическое следствие это понятно

(100) но поскольку новые конфигурации идут в управляемом режиме, то это для них не существенно. А старые надо адаптировать, это не особо сложно, раз уж хочется воспользоваться ораклом.

(99) 7.7 поддерживала только MSSQL. А 8-ка, на минуточку - четыре разных СУБД. Если немножко подумать головой - то это абсолютно правильное решение. Вкладываться в условиях кросс-платформенности в глубокую оптимизацию под конкретные СУБД - это немерянный головняк и экономический бесперспективняк.

(94) Тогда в этом 1С не причем. В версионниках нет возможности блокировать строки на чтение - это противоречит их версионной природе. А у 1с в автоматическом режиме нет возможности обеспечить управляемые блокировки на нужные строки. Поэтому там используется блокировка таблиц, иначе нельзя заставить читающую транзакцию ЖДАТЬ пока завершится запись.

(102) всё равно под MS SQL платформа работает лучше, чем под остальными СУБД. Не думаю, что использование хранимых процедур считается ГЛУБОКОЙ оптимизацией.

(104) Ну а теперь считай затраты - это объекты метаданных, которыми надо управлять, целостность которых нужно поддерживать, обеспечивать работоспособность и совместимость в разных версиях MSSQL. Плюс реализация в разных СУБД - разная.
На поддержку этой лабуды нужно дополнительно немало нехилых спецов. И все равно воплей про "глюкавость" станет в разы больше, т.к. количество потенциальных источников глюкавости умножится.

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

(106) поддержка разных СУБД реализована в разных ДЛЛ, полагаю, что интерфейс для остальной части 1С у них максимально похожий. И их и так разрабатывают разные спецы.
Я как-то больше о механизме пересчёта итогов регистров думал, который выполняется при любой записи в него, так и просится в в виде триггера реализовать.

Мне нечего добавить к уже сказанному и лениво долго дискутировать об очевидных для меня вещах.
С наступающими!