НачатьТранзакцию

Запрос.Выполнить("Тут запрос по регистру, по которому конфликт")

ДокОб.Записать(Проведени) //вот тут конфликт

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

или такая схема

НачатьТранзакцию

БлокировкаДанных.Заблокировать() //блокировка по регистру

ДокОб.Записать(Проведени) //вот тут конфликт которые выше был заблокирован

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

Вроде как получается что транзакция проведения (записи) не видит транзакцию, которая выше и получается конфликт?

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

переходи на упр блокировки

в одном сеансе не бывает конфликтов блокировок

(2) сфига ли не бывает. когда конфликт это разные транзакции а не сеанс.

сеанс в 1с однопоточный

(4) и чо. нельзя сделать одновременно 2 транзакции что ли?

я вот не 1й раз уже сталкиваюсь когда

начатьтранзакцию

тут запрос к регистру или каким-то данным объектам

тут запись или проведени и все = привет конфликт блокировок

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

если сделать так

тут запрос к регистру или каким-то данным объектам

начатьтранзакцию

тут запись или проведение, то все норм

зафиксироватьтранзакцию

Вам бы почитать мануалов.

да я сам знаю что надо почитать. будет время почитаю

Когда запрос выносим за транзакцию - на уровне СУБД режим изоляции - Uncommited Read, который снимается как только запрос закончится.
Когда запрос вносим в транзакцию - на уровне СУБД режим изоляции
1) RepeatableRead с S блокировкой до конца транзакции при автоматических блокировках, которая дает взаимоблокировку с X блокировкой Записать().
2) ReadCommited с S блокировкой на момент выполнения запроса при управляемых блокировках, которая не даст взаимоблокировку с X блокировкой Записать() но может исказить обработку результата запроса.
3) ReadCommited snapshot в 8.3 без блокировок на момент выполнения запроса при управляемых блокировках, которая не даст взаимоблокировку с X блокировкой Записать() но может исказить обработку результата запроса.

(8) 2) а как может исказить обработку результата?

(9) + у меня, например, данные меняются до запроса, а потом запросом выбираются эти измененные. (все это в транзакции)

Чтобы обойти проблему 1 в автоматическом режиме в запросе есть оператор ДЛЯИЗМЕНЕНИЯ, который меняет S блокировку на X блокировку на этапе Запроса.

Чтобы обойти проблему 2 и 3 в управляемом режиме есть Объект БлокировкаДанных, которая позволяет наложить X блокировку из кода 1С на уровне сервера 1C не опускаясь до уровня СУБД, ну, либо обработка результата Записать() постфактум и откат транзакции.

(9) 1 транзакция выполнила запрос, s блокировка снята (read commited), либо не накладывалась (read commited snapshot), результат запроса сохранен в ТЗ или выборке, а в это время 2 транзакция сделала Записать(). В базе данные изменились, в ТЗ или выборке - нет.

(11) Не Х,а U - на SQL, хотя они и похожи.

(8) все прекрасно, но автор говорит, что у него один сеанс

(12) а, понял...ты про "грязное" чтение
но это будет и без транзакции...

возможно в коде есть какойто алгоритм формирования движений через фоновые задания

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

(17) тупанул...не грязное, а неповторяющееся чтение...