А это правда, что в 8.2 ПодпискаНаСобытиеЗаписиДокумента вызывает транзакцию в режиме автоматической блокировки таблиц, не смотря на то, что конфигурация находится в управляемом режиме блокировок?

P.S. Мне недавно на одной авторитетной встрече так сказали.

Может кто пояснить эту ситуацию?

+(0) и документ тоже находится в режиме управляемых блокировок

>> вызывает транзакцию
ПриЗаписи уже выполняется в транзакции. Какую транзакцию еще вызывает?

(3) фиг знает, мне так сказали на одной встрече. Человек меня опрашивал, и так мне сказал...

(4) я и удивился, хочу узнать мнения

+(5) жаль, я провафлил и в ответ не спросил: "А как ты это узнал"?

(6) провафлил ??? &!&!!!!!

(7) это я попытался  так выразить свою раздосадованность... чето перегнул я...

кто-нить рискнет первым проголосовать?

(9) чем подтвержден авторитет утверждающего? ты уверен, что все правильно понял?

(10) начальник отдела программистов большой и денежной фирмы в сфере медицинских услуг

(0)По отдельности каждое слово понятно. А вот смысла не уловил. Задай вопрос более развёрнуто ))

(12) конфигурация:
- управляемые формы
- режим блокировок конфигурации управляемый и распространен на все документы

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

Это понятно? Это правда?

Я так понимаю, что по идее транзакцию начинает сам документ, а раз он проводится в управляемом режиме, то этот режим распространяется на всю транзакцию.
И если внутри транзакции появится что-то в автоматическом режиме, то будет ошибка.

По идее, подписка на событие тут вообще не при чем. Или я не прав?

(14)Полагаю не причем.

(15) Спасибо за ответ.
Давайте проголосуем?

Добавь в голосовалку. 4. Это не при чём.
Так точнее. Вариант 2 предполагает связь двух понятий, а связи может и не быть.

При вызове НачатьТранзакцию(РежимБлокировки.Автоматический) внутри управляемой - вызывается исключение. Все подписки внутри одной транзакции работают.

(17) а как это можно определить точно? Как ты думаешь?

(18) внутри управляемой конфигурации или управляемого ДокументОбъекта?

Зачем спрашивать? Проведи эксперимент!
Останови код в процедуре подписки на точке останова, а в другом сеансе попробуй записать/изменить данные там, где они, по твоему предположению, заблокированы.

(21) тоже вариант, надо будет над ним подумать :)

(20) внутри управляеемой транзакции. попробуй в управляемой транзакции записать начать автоматическую транзакцию

(23) отказ будет

Понятия уровня вложенности транзакций физически в 1С не существует, запускается одна транзакция и проверяет флаги "управляемый или автоматический" у регистров и проводимых документов.

Или я ошибаюсь?

(22) чего тут думать - трясти надо ;)

Я думаю, что да

Описание:
Возникает при записи объекта. Процедура-обработчик вызывается после записи объекта в базу данных, но до окончания транзакции записи.


При наступлении события указанного события выполняется следующая последовательность действий:

- сначала отрабатывается событие в самом объекте и вызывается обработчик события, определенный в модуле объекта или набора записей;
- если в процессе выполнения обработчика параметр Отказ установлен в значение Истина или вызвано исключение, действие прерывается;
- затем вызываются в произвольном порядке внешние обработчики, назначенные для данного события;
- в качестве источника в назначенный обработчик передается сам объект (набор записей) вызвавший событие;
- если в процессе выполнения назначенного обработчика параметр Отказ установлен в значение Истина или вызвано исключение, действие прерывается.

(27) последовательность действий и транзакция - это разные вещи

(27) Документ записывается с проведением - начинается ОДНА транзакция в управляемом режиме блокировок. Если внутри этой транзакции встретится регистр или что-то еще у чего стоит признак "автоматическая блокировка", то возникнет отказ в выполнении.

Господа, высказывайте свое мнение и голосуйте - это очень важно!

upну

что, на бутылку поспорил?

(32) хочу понимать, зачем такие утверждения говорятся кандидатам на собеседовании?

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

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

(33) да, ловушки на собеседовании - обычное дело.

собеседователь так не думает.

(35) а может он действительно так думает и собеседует людей в поисках "настоящего спеца"?

(37)-(36)

(38) т.е. надо было вступить в полемику и с пеной у рта доказывать, что это не так?

Недостаточно было просто сказать "удивительно, никогда бы не подумал"?

2(37)спроси почему он так думает, и как он проводил повторяемые эксперименты, чтобы убедиться в своем утверждении.

(40) такая хорошая мысля пришла мне опосля :)

Если он просто начнет ссылаться на то, что он лично видел, как в 20% случаев что-то такое происходило, то лучше не устраиваться на это место

(39) надо было говорить "странно, у меня - не так", а "никогда бы не подумал" говорит о том, что ты этого не знаешь твердоЪ

завалили тебя, в общем

(44) видимо да

самое грамотное "но моя практика/опыт показывает, что это не так"

(46) Да, достойный вариант ответа

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

(48) тоже так думаю

(0) что значит автоматическая блокировка?

(50) режим управления блокировкой данных

(51) а без громких лозунгов, что это такое на пальцах

(52) сходи на курсы

я их сам веду, мне интересно твое понимание

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

Как правило, блокируются все таблицы, в которые будет осуществляться запись.

+(55) встроенный менеджер блокировок в системе есть

+(55) даже если запись в таблицу регистра осуществляться не будет, но документ является регистратором для этой таблицы - она тоже полностью блокируется

Хех :) Следующий вопрос будет про "таблицы".

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

(57) твоё понимание автоматической блокировки неверное

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

В управляемом режиме, "Для изменения" игнорируется менеджером блокировок.

(59) А как правильно?

(58) подписка на событие тут вообще не при чем.
Даже если я не правильно понял собеседника, то зачем он приплел подписку на событие к блокировкам?

(61) Это режим работы 1с:Предприятия, когда все блокировки делаются средствами СУБД в соответствии с уровнем изоляции транзакций Repeatable Read или Serializable(любое чтение в транзакции вызывает разделяемую блокировку), что обеспечивает логическую целостность данных, но создаёт избыточные блокировки. Блокироваться при этом могут и записи, не обязательно все таблицы.

(62) возможно он имел ввиду уровни изоляции транзакций

(64) Я только что проверил - подписка выполнялась на установленном изначально read committed и отдельную транзакцию  вообще не начинала.

(63) Если бы у меня под рукой была методичка, я бы тоже воспользовался "копировать-вставить" :)

(63) в файловой базе данных никакого сочетания "Repeatable Read или Serializable"  быть не может

(66) Причем тут методочка? Я тебе как раз своими словами сказал. Ну и файловая работает на как раз на Serializable - ты зря начинаешь спорить, явно плаваешь в вопросе.

(68) вот с этого давай поподробнее.

Ты можешь в 1С определить когда запускается Serializable, а когда Repeatable Read?

+(69) в автоматическом режиме?

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

Автор топика не разобрался в вопросе.

(71) ты троллишь, что-ли? Я тебе выше об этом говорил.

(71) Мы СУБД не касаемся, не уводи разговор в сторону.

Ты в 1С начинаешь транзакцию в автоматическом режиме.
Откуда ты знаешь, она Serializable или Repeatable Read?

(73) Друг, научись понимать логические выражения - для программиста полезно.
Если я говорю, что в автоматическом режиме будет Serializable или  Repeatable Read, то когда в частном случае файловой БД мы имеем Serializable, то выражение (Serializable или  Repeatable Read) истинно.

Автору или читать про св-во конфигруации РежимУправленияБлокировкойДанных или формулировать вопросы внятнее

если дословно понимать что РежимУправленияБлокировкойДанных=Управляемый то:

(74) Ты продолжаешь обнажать своё невежество. Понятие изоляции транзакций относится к СУБД, а не к 1С. Файловая БД - это тоже вариант СУБД, которая умеет работать только на одном уровне изоляций.

(75) Дорогой, я просто хочу навести тебя на мысль и получить ответы:
- а нафига мне знать про "Serializable или  Repeatable Read" если транзакция в автоматическом режиме?
- как это знание мне поможет в 1С в этом режиме блокировок?

(74) без СУБД разговор не имеет смысла

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

(80) нафига засирять себе мозг ненужными в ситуации (78) вещами?

(81) Когда пишешь масштабируемые решения это необходимо. Например, в автоматическом режиме иногда нужно ставить "Для изменения" в запросе, чтобы повысить уровень блокировки до экслюзивного, чтобы не было взаимоблокировки. Чтобы понимать, зачем это нужно, надо понимать работу 1с на уровне изоляции транзакций в автоматическом режиме.

(81) "Для изменения" это вообще явная установка исключительной блокировки, по сути даже в автоматическом режиме блокировками управлять приходится, иначе остатки контролировать не сможешь.

(80) на разных данных одна и та же база работает по разному

(82) "Для Изменения" в автоблокировках используется как раз в том случае, если ты хочешь железобетонно заблокировать таблицу в режиме Serializable

(84) Это очень общая фраза, с которой невозможно спорить и которая не несет смысла.

(85) Блокировка накладывается исключительная или разделяемая, а не "Serializable"

+(85) вернее, записи таблицы, попавшие в запрос

(85) И не всю таблицу, а записи, если СУБД так решит.

(87) да, Serializable и прочие аглицкие термины, отдельно от СУБД к 1С не применимы

(89) ---> (88)

(88) А иногда - и всю таблицу, если СУБД решит что ресурсов для блокировки записей тратиться слишком много.

(92) ты когда разрабатываешь в 1С, каждый раз думаешь, что происходит в SQL?

(90) Ты путаешь режим блокировки и уровень изоляций, ну как с тобой о чем-то спорить?

(92) Ты не поверишь - да.

(94) ты со своим уровнем изоляций пытаешься затроллить меня на разговор о СУБД и уйти от платформы 1С

(95) от у тебя мозг наверно пухнет...

(90) Ты путаешь уровень изоляции транзакций и режим блокировки. Это как бы очень демонстрирует знание вопроса.

(96) Ты изначально начал говорить о СУБД, как только написал в топике про блокировки. Блокировки - это всегда связано с СУБД, не зная работы СУБД можно даже не соваться в блокировки.

(98) каким образом платформа 1С относится к понятию "уровень изоляции транзакции", если этим управляет не платформа, а СУБД?

(96) Тем более, автоматический режим блокировок - это вообще абсолютно не связанная с 1С вещь, реализуемая именно СУБД, а не платформой, за исключением "Для изменения"

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

(102) Насколько я знаю, в 1С свой менеджер блокировок, который никоим образом не относится к управлению уровнями изоляции транзакций в СУБД.

Или ты опять скажешь, что я не прав?

(103) ага

(102) Есть свой менеджер блокировок, да. И что? Он нужен для того, чтобы в тех случаях, когда СУБД блокировку не поставить, поставить её самостоятельно. СУБД не будет ставить блокировки при чтении таблиц в транзакции на уровне Read comitted, но будет на уровне Repeatable Read, значит, если из логики работы нашей базы следует, что блокировка там нужна, это нужно делать самостоятельно - через менеджер блокировок. Не учитывать изоляции транзакций нельзя, т.к. блокировки СУБД накладывает в любом случае, нужно понимать в каком случае какие блокировки она наложит, чтобы средствами 1С обойти взаимоблокировки и чтобы обеспечивать целостность данных.

(104) тогда поясни, будь ласка :)

(105) тогда при чем тут "Для изменения" и уровень изоляции транзакций в СУБД?

(107) "для изменения" - это средство обеспечить целостность данных и обойти взаимоблокировку путем повышения уровня блокировки, которую накладывает СУБД, средствами 1С

(108) Думаешь, что если в запросе ты написал "Для изменения", то СУБД наложит другой уровень изоляции?

+(109) ты можешь на этот вопрос ответить "Да" или "Нет"?

(109) Это ты так думаешь. На самом деле СУБД повысит уровень блокировки до исключительного.

(111) ты уверен в том, что именно СУБД повысит уровень блокировки?

(112) В случае с "Для изменения" - да.

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

(114) Ты продолжаешь обнажать своё невежество. Менеджер блокировок используется в управляемом режиме. "Для изменения" - автоматический режим.

(115) Т.е. я пишу запрос и указываю в нем "Для изменения".
В СУБД возникает соответствующий уровень изоляции транзакций?

А может все по-другому?

Сервер приложения получает результат запроса от SQL и в результате запроса накладывает свои блокировки на записи?

(114) Ну и эта, на уровни изоляции транзакций не влияет и "Для изменения" - он влияет на уровень блокировки. Я тебе подскажу - их два: разделяемая и исключительная.

(116) Прекрати немедленно нести чушь про смену уровня изоляций от конструкции "Для изменения".

+(116) Очень хочу, чтобы ты помог мне разобраться в моем невежестве. Особеннно вот в этом:

Сервер приложения получает результат запроса (в котором ДЛЯИЗМЕНЕНИЯ) от SQL и в результате запроса накладывает свои блокировки на записи или СУБД меняет уровень изоляций?

(119) Система транслирует Для изменения в "For update" на SQL, что вызовет на СУБД исключительную блокировку по записям.

(118) Имхо, я пытаюсь тебя понять и осмыслить свою чушь.

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

(119) Прекрати немедленно нести чушь про смену уровня изоляций от конструкции "Для изменения".

(112) Немедленно ответь мне на все вопросы

(121) В управляемом режиме так и есть - блокировками управляем менеджер. При это блокировки на СУБД также присутствуют - любая запись делает блокировку на чтение.

(124) собственно, для изменения именно поэтому и не работает в управляемом режиме.

(124) У нас разговор вообще-то шел про автоматический режим, а не про управляемый.

В свете управляемого режима, ДляИзменения тупо игнорируется платформой.

(125) Т.е. ты хочешь сказать, что в автоматическом режиме, ДляИзменения передается напрямую в SQL и он, ориентируясь на это слово накладывает дополнительные блокировки?

(126) В 8.0 был автоматический режим. В 8.0 не было менеджера блокировок вообще. Про какое управление блокировками на стороне 1С в автоматическом режиме ты говоришь?

(126) не прав

(127) Ты еще 10 раз спроси меня одно и тоже. Да, так и есть.

(130) ну ты сразу бы так ответил...

(130) тогда я не понимаю, как вяжется между собой (126) и утверждение в (129)?

(131) Когда ты говоришь "Для изменения" заставляет менять уровень изоляций на СУБД - я не могу на такое ответить "Да"

(133) Ну если "ДляИзменения" передается на прямую в SQL и SQL накладывает блокировки на записи, то это должно существовать и в управляемом режиме и не зависеть от менеджера блокировок платформы.

Что-то тут не вяжется... Можешь пояснить?

(134) блокировка накладывается, но действует не до конца транзакции, а снимается после выполнения запроса

(135) Т.е. ДляИзменения работает и в управляемом режиме?

Почему у меня тогда в методичке запись, что применение "ДляИзменения" не несет в себе смысла в режиме управляемых блокировок?

(136) и даже вредна, блокирует то что не может удержать до момента записи

(137) вона оно как.
Видать преподаватель не знал четко и отделался общей фразой, что "применение "ДляИзменения" не несет в себе смысла в режиме управляемых блокировок".

А я уже додумал, что оно игнорируется платформой.

Спасибо.

(138) Тебя вводят в заблуждение - конструкция "Для изменения" не влияет в управляемом режиме, как минимум на сторону СУБД она тупо не передается.

Запрос с "Для изменения" на стороне MS SQL 2008R2 в управляемом (1) и автоматическом (2) режимах:

SELECT
T1._IDRRef
FROM _Reference7 T1

SELECT
T1._IDRRef
FROM _Reference7 T1 WITH(REPEATABLEREAD, UPDLOCK)

(140)
Спасибо.
Значит все-таки "Для изменения" игнорируется платформой в управляемом режиме и передается в SQL в автоматическом режиме.

+(141) А то уже хотел лезть и ДляИзменения вычищать :)

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

Описано косвено в ЖКК.

(143) > Если в транзакции не указывать про режим, то будет блокировка по умолчанию (автоматическая)

Это неверное утверждение.

+(145) Если ты записываешь документ, на котором "Управляемый режим", то транзакция начнется в управляемом режиме.

(145) То есть ты создал пост, чтобы доказать сам себе что тебя не справедливо слили с собеседования ?

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

(146) Ты там пишешь БлокировкаДанных
РежимБлокировкиДанных.Разделяемый или РежимБлокировкиДанных.Эксклюзивный.
А подписка пихает твою транзакцию в свою внешнюю.

(149) тогда проголосуй как правильно

Всю жизнь думал, что не подписка создает транзакцию....

+(150) а событие начала записи документа

(149) т.е. ты утверждаешь, что подписка на событие первична и она создает транзакцию?

(148) Ну вот на первом месте "мои знания верны". Признай уже наконец поражение. Это спец вопрос на который 99 процентов 1Сников не ответит, потому как вряд ли им это когда нибудь в работе пригодится и смысл которого посадить коллегу в лужу, доказав что он не так крут как тот кто спрашивает :)

(143) Расскажи побольше про инициацию транзакций подписками и особенно про фразу "по умолчанию (автоматическая)".

(146) Свойство документа не влияет на режим блокировок, если для конфигурации установлен "Управляемый".

мля не одного поста не понял, пошел читать)

(152) я тебе скопипастил на 1 странице из документации по платформе. Подписка создает свою транзакцию, внутри которой твоя управляемая. А в итоге будет тот режим который у транзакции подписки.

(157) Какая подписка? Я так понимаю, речь про подписки типа "Перед записью"? Я проверял трассировкой - уровень read comitted во всех транзакциях.

(157) Подписки вида "призаписи" или "припроведении" вообще не могут транзакцию начинать, так как выполняются внутри транзакции записи документа, а, как было сказано выше, фактически поддержки вложенных транзакций в 1С нет, всё выполняется в первой транзакции.

Или даже наоборот будет вложенной транзакция ПриЗаписи в твою управляемую блокировку, все равно общий эффект будет с тем режимом какой у транзакции подписки.

(157) На курсах утвердали, что платформа 1С не поддерживает вложенность транзакций. Транзакция всегда ОДНА.

В коде можно писать много уровней вложенности транзакций, но это игнорируется платформой и транзакция всегда ОДНА.

(161) Не игнорируется, там есть счетчик и менеджер блокировок отслеживает уровни, но на СУБД это всегда 1 транзакция.

(162) Запутался. Давай забудем про СУБД. В платформе транзакция ОДНА?

(159) А ПередЗаписьюСобытиеПодписки может транзакцию начинать?

(163) Одна, одна.
У 8vС1 какая то cвоя 1С c внешними транзакциями

(162)
НачатьТранзакцию()
//Изменение данных №1
     
       НачатьТранзакцию()
     //Изменение данных №2
     ОтменитьТранзакцию()
     ЗафиксироватьТранзакцию()

ЗафиксироватьТранзакцию()

Утверждаешь, что, изменение данных №2 откатится?

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

(165) Спасибо :)

Да написано, что вложенные транзакции не поддерживаются. Тода хз почему так.
Написано, что
в качестве источника в назначенный обработчик передается сам объект (набор записей) вызвавший событие;
то есть, как я понимаю он уже должен быть записан в базу.

(166) Rollback - это действие СУБД, не 1С.

(167) Спасибо,пора составлять список людей, кому можно верить, а кому нет :)

(169) Объект и набор записей - это не записи в БД, это мутабельные значения, которые существуют только в приложении 1С.

(172) ого, Леха, ну ты разошелся)
может и мне по роутеру объяснишь?

(173) Давай, я сегодня в боевом настрое!!:)

269 105 673
тим вьюер 7

2i52fa

Ну если трассировка выдала read commited значит управляемый режим однозначно.