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

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

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

(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 значит управляемый режим однозначно.