Ребята, кто рубит в управляемых блокировках, поможите, чем можите. Перевожу УТ 10.3 на управляемые блокировки. Начал с документа реализации. В обработке проведения (при перепроведении) в самом начале стоит удаление записей регистров. После записи пустого набора в регистр сведений "Списанные товары", другие документы стоят колом, т.е. не могут провестись, пока не закончится проводиться первый документ. Хотя после удаления записей других регистров другие документы могут проводится. Причем стопорится проведение при выполнении запроса по партиям, там есть запрос к регистру списаний и в этом запросе стоит отбор по регистратору. Не ясно что именно блокируется, в регистре всего лишь одно измерение - номер строки, и регистр подчинен регистратору. Да, кстати, если проводить реализацию с непересекающейся номенклатурой, все проводится нормально, а если хотя бы одна номенклатура пересекается, то документ блокируется независимо от склада.

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

+1, но тут нужно подумать, не будет ли тормозов, если начнешь ТЗ на сервер таскать...

А вообще, тоже интересна эта тема...

Т.е. если идет запись в этот регистр, то никакие управляемые блокировки не спасут без изменения алгоритмов проведения?

(4) Судя по твоему описанию проблемы, видимо накладываются неявные блокировки на регистр списанные товары по номенклатуре. Посмотри на индексированность ресурса Номенклатура. Если индекс есть, а блокировки идут, то видимо ничего ты с этим уже не сделаешь без изменения алгоритма. В измерениях у тебя только номер строки, номенклатуры нет...

Не, гоню в (5).

(0) режим блокировки для РС "СписанныеТовары" = "Управляемый"?

(6) :-)
(7) Обязательно

Просто только изучаю эту тему, не пойму, при записи пустого набора в этот регистр сведений, по идее, должны блокироваться все записи, которые подчинены регистратору. Почему другие документы не могут выполнить запрос к данному регистру, ведь в нем идет условие "Где Регистратор = &Ссылка". Нифига не пойму.

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

(9) Попробуй явно заблокировать набор записей по регистратору (с помощью объекта "БлокировкаДанных") перед удалением движений.

(10) Ясно, клиенту обязательно нужно проведение по партиям в реальном времени, так что придется лопатить алгоритм! Хотя сейчас еще попробую проиндексировать Склад в Списанных товарах, может что даст! Спасибо selenat!

(11) Блокировал, ничего не дает (

(12) мне не за что. Я высказываюсь с ходу на правах бреда. Попробуй вот лучше (11)...

(13) а если снять индекс с ресурсов номенклатура и номенклатураСтарая?

т.е. номенклатура и НоменклатураНовая

индексы никак не влияют на управляемые блокировки. Тем более индексы ресурсов

(17) мало ли. Почему тогда (13)?

(17) Уже начал индексировать Склад, сейчас доиндексируется посмотрим, lxndr может ты знаешь, что там блокируется тогда? И почему именно с одинаковой номенклатурой не проводится, а с одинаковым складом проводится?

(19) ты отпишись потом о результате. Я тоже в будущем собираюсь такое сделать...

(20) Обязательно

А какие измерения в регистре "Списанные товары"

(22) НомерСтрокиДокумента

(0) при записи пустого набора явно указывается отбор по регистратору?

(24) Набор.Отбор.Регистратор.Установить(ДокументОбъект.Ссылка) - вот так

(25) А если так
Набор.Отбор.Регистратор.Установить(ДокументОбъект.Ссылка)
Набор.Прочитать();
Набор.Очистить();
Набор.Записать();

(26) обязательно попробую и отпишусь, как реструктуризация закончится.

(0) А может проблема все же в блокировках по регистру ПартииТоваровНаСкладах? Я бы посмотрел на план выполнения запроса и на блокировки SQL на момент выполнения запроса.

(28) Я делаю так - ставлю точку останова в процедуре удаления регистров, открываю еще одну сессию и пытаюсь проводить документ во второй сессии, документ перестает проводиться именно после удаления регистра списание. А как можно глянуть план запроса? Может есть статья хорошая?

(29) с помощью sql profiler. Поищи тут: kb.1c.ru или gilev.ru

(30) ок, спасибо

(29) Вот тут http://infostart.ru/public/56973/ есть обработка, которая покажет сразу план

ну и про ЦУП не забудем :) http://v8.1c.ru/expert/pmc/pmc_overview.htm

(33) ЦУП дорогой зараза ))

В общем сделал индексацию по складу - не помогло, сделал как 1C-Nick в (26) посоветовал - не помогло. А блокировки тоже с помощью профайлера смотреть?

(35) теперь сними индекс и со складов, и с номенклатуры (причем и с новых тоже).

(0) Включите Режим разделения итогов котрый поднимает поле SPLITER в итогах и будет возможно счастье.

(36) Сейчас попробую.

(37), ок, после (36) попробую

А причем тут Списанные товары?
Скорее всего блокируется Партии товаров на складах

(0) Так в конфе режим разделения итогов поднят или нет ? Автор , колитесь ? :)

(37) Если регистр сведений, то у него нет ни итогов, ни разделителя.

(40) не знаю Мебиус, посмотри (29)

Индексация Склада ничего не даст

Передвинь Склад  вверх в списке
тогда по идее ресурс будет не Номенклатура
а Склад + Номенклатура

в списке измерений

регистра Партии товаров

(35) Я смотрю блокировки вот так
Create Table #locks
     (spid       int,
     dbid       int,
     objid       int,
     indid       int,
     type       char(5),
     Resource nvarchar(255),
     Mode      nvarchar(255),
     Status      nvarchar(255)
)

Insert #Locks Exec Master.dbo.sp_lock
Select distinct  spid, OBJECT_NAME(objid, dbid), type, mode from #Locks where dbid=66
DROP TABLE #Locks dbid должен быть твоей базы

(46), хорошо, сейчас буду все пробовать

(47) Понял, спасибо

И еще, я в процедуре проведения явно блокирую регистр Партий вот так:

ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ПартииТоваровНаСкладах");
ЭлементБлокировки.Режим    = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ТаблицаПоТоварам;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад","Склад");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура","Номенклатура");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("ХарактеристикаНоменклатуры","ХарактеристикаНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("СерияНоменклатуры","СерияНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Качество","Качество");

т.е. по идее не должен регистр партии блокироваться.

Кстати, какой тег использовать, чтобы код был выделен отдельно в посте? ))

О пардон, даже тега не надо )

(50) метод "Заблокировать()", надеюсь, вызываешь?

(52) Да

Вообще то
если это ИМЕННО управляемый режим то уровень изоляции READ COMMITED

READ COMMITED -  обеспечивает запрет «грязного» чтения. Если моя транзакция начала изменять данные, то конкурирующая транзакция не может не только измененить, но даже прочитать их до завершения моих изменений. После того, как мои изменения закончены, конкурирующие транзакции могут читать данные, не дожидаясь окончания моей транзакции в целом. Таким образом существует проблема неповторяемого чтения.

(50)
Попробуй закомментиовать код

Удалил по совету selenat'а индексы со склада, номенклатуры и номенклатурыстарой в регистре СписанныеТовары - теперь после удаления записей регистра документы проводятся, дошел до регистра "ТоварыОрганизации", на нем то же самое, сейчас буду разбираться. Радует, что есть продвижение.

(56) странно...

(57 )Очень :-)

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

(59) Не знаю, удалю если что, код нашел в инете уже давно, а что нельзя заблокировать неиндексированное поле?

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

(56) как успехи?

(0) Делал без регистра СписанныеТовары: экспортные процедуры в документах, которые формируют нужную таблицу (это для неоперативного списания). В самом документе эта таблица передается в процедуру ДвижениеПартийТоваров, в которой (если не передана таблица, вазывалась экспортная процедура).

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

(64) Да что-то он здоровый стал (больше Гига), вот и ликвидировал.

(65) тоже верно...

(62) Сейчас стопорится на регистре ТоварыОрганизации, причем стопорится очень выборочно, т.е. один документ проводится, а другой, с такими же реквизитами и табличной частью - нет.

(67) С ТоварамиОрганизаций все нормально, теперь остался последний регистр - партии товаров на складах, именно после удаления его записей другие документы не могут проводиться, причем независимо от того, какая номенклатура, склад и т.д. в них заполнены. Т.е. не проводится ничего, поставил режим разделения итогов - ничего не поменялось, двинул склад выше номенклатуры, то же самое. Может у кого будут еще какие мысли?

(68) Если не смотреть план запроса, на котором возникает блокировка, то можно долго экспериментировать.

(69) Ага, я вот сейчас с профайлом разбираюсь

(68) а что сделал с ТоварамиОрганизаций?

(71) Там глюк какой-то, все документы проводятся, а последний в списке нет, даже не знаю с чем связано.

(68) а где ты вставляешь код управляемых блокировок?

+73 код из (25) где находится?

(74) Код управляемых блокировок убрал пока вообще, потому что разницы нет, что так, что так таблица блокируется полностью. А код из (25) находится в общем модуле "ОбщегоНазначения" и вызывается в самом начале обработчика проведения.

(75) как это разницы нет? Как это таблица блокируется полностью? Не верю. Даже при автоматических блокировках она блокируется не полностью, а с учетом индексированных полей. У тебя ведь скульная база?

(75) в какой процедуре был этот код? Можешь привести ее полностью с этим кодом?

(76) БлокировкаДанных это блокировка, которая не передается SQL серверу, а хранится на сервере 1С. При поступлении запроса на блокировку от другого сеанса, в случае пересечения блокируемых данных, ожидание будет на методе Заблокировать(). Без БлокировкаДанных все блокировки SQL будет устанавливать сам и возможно возникнет deadlock.
Наличие индексируемых полей не влияет на БлокировкуДанных, но влияет на блокировки SQL. В случае отсутствия индекса может выполняться scan который заблокирует лижние записи.

(78) ну автор же пишет, что данные блокируются даже непересекающиеся, что болкируется вся таблица.

(76) База скульная, именно после удаления набора записей вообще перестают документы проводиться.

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

(79) Допустим мы наложили упраляемую блокировку по нужным нам измерениям, другая управляемая блокировка наложится по другим измерениям, все замечательно, а вот запрос, выполняющийся на SQL из-за отсутствия подходящих индексов заблокирует диапазон значений и ТС похоже сталкивается именно с такими блокировками.

(77) Алгоритм проведения такой:

1) Заходим в обработку проведения;
2) Ставим управляемые блокировки на наборы записей регистров по регистратору (хотя толку от этого нет);
3) Идет удаление записей регистров;
4) Ставим управляемые блокировки вот такой процедурой (что с этой процедурой, что без нее разницы не ощущаю):

Блокировка = Новый БлокировкаДанных;
//Блокировка по товарам на складах
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ТаблицаПоТоварам;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура"    ,"Номенклатура");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("ХарактеристикаНоменклатуры","ХарактеристикаНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад" ,"Склад");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("СерияНоменклатуры","СерияНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Качество" ,"Качество");
   
//списанные товары
ЭлементБлокировки = Блокировка.Добавить("РегистрСведений.СписанныеТовары.НаборЗаписей");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение("Регистратор",Ссылка);
   
//Блокировка по товары организаций
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыОрганизаций");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
   
ЭлементБлокировки.УстановитьЗначение("Организация",СтруктураШапкиДокумента.Организация);
   
ЭлементБлокировки.ИсточникДанных    =  ТаблицаПоТоварам;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура"     ,"Номенклатура");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("ХарактеристикаНоменклатуры" ,"ХарактеристикаНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("СерияНоменклатуры" ,"СерияНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Качество" ,"Качество");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад" ,"Склад");
   
ПроводитьПоПартиям = РегистрыСведений.УчетнаяПолитика.ПолучитьПоследнее(Дата).СписыватьПартииПриПроведенииДокументов;
Если ПроводитьПоПартиям Тогда
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ПартииТоваровНаСкладах");
       
ЭлементБлокировки.Режим    = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ТаблицаПоТоварам;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад","Склад");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура"    ,"Номенклатура");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("ХарактеристикаНоменклатуры","ХарактеристикаНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("СерияНоменклатуры","СерияНоменклатуры");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Качество","Качество");
КонецЕсли;
   
Блокировка.Заблокировать();

5) Проводим по регистрам;

(82) но ведь он сталкивается с этим же не только при управляемых, но и при автоматических, которые строятся по индексам. Если конечно я правильно его понял. Как это может быть?

Вот процедура удаления записей:

Процедура УдалитьДвиженияРегистратора(ДокументОбъект, Отказ, ЗамещатьДвижение = Истина) Экспорт
   
   МассивОбрабатываемыхСтрокТаблицыДвижений = Новый Массив();
   
   // получение списка регистров, по которым существуют движения
   ТаблицаДвижений = ПолныеПрава.ОпределитьНаличиеДвиженийПоРегистратору(ДокументОбъект.Ссылка);
   ТаблицаДвижений.Колонки.Добавить("НаборЗаписей");
   ТаблицаДвижений.Колонки.Добавить("БезусловноеУдаление", Новый ОписаниеТипов("Булево"));
       
   Для Каждого СтрокаДвижения ИЗ ТаблицаДвижений Цикл
       // имя регистра передается как значение, полученное с помощью
       // функции ПолноеИмя() метаданных регистра
       ПозицияТочки = Найти(СтрокаДвижения.Имя, ".");
       ТипРегистра = Лев(СтрокаДвижения.Имя, ПозицияТочки - 1);
       ИмяРегистра = СокрП(Сред(СтрокаДвижения.Имя, ПозицияТочки + 1));

       МассивОбрабатываемыхСтрокТаблицыДвижений.Добавить(СтрокаДвижения);
       
       ЕСли ТипРегистра = "РегистрНакопления" Тогда
           Набор = РегистрыНакопления[ИмяРегистра].СоздатьНаборЗаписей();
               
       ИначеЕсли ТипРегистра = "РегистрСведений" Тогда
           Набор = РегистрыСведений[ИмяРегистра].СоздатьНаборЗаписей();              
               
       КонецЕсли;

       Если НЕ ПравоДоступа("Изменение", Набор.Метаданные()) Тогда
           // отсутствуют права на всю таблицу регистра
           СообщитьОбОшибке("Нарушение прав доступа", Отказ, СтрокаДвижения.Имя);
           Возврат;
       КонецЕсли;

       Набор.Отбор.Регистратор.Установить(ДокументОбъект.Ссылка);            

       // набор не записывается сразу, чтобы не откатывать транзакцию, если впоследствии
       // выяснится, что на один из регистров не хватает прав.        
       СтрокаДвижения.НаборЗаписей = Набор;        
       
   КонецЦикла;    
   
   Для Каждого СтрокаДвижения ИЗ МассивОбрабатываемыхСтрокТаблицыДвижений Цикл        
       Если СтрокаДвижения.БезусловноеУдаление Тогда
           ПолныеПрава.ЗаписатьНаборЗаписейНаСервере(СтрокаДвижения.НаборЗаписей, ДокументОбъект.Ссылка);
       Иначе        
           Попытка
               СтрокаДвижения.НаборЗаписей.Прочитать();
               СтрокаДвижения.НаборЗаписей.Очистить();
               СтрокаДвижения.НаборЗаписей.Записать();
           Исключение
               // возможно «сработал» RLS или механизм даты запрета изменения
               СообщитьОбОшибке(ОписаниеОшибки(), Отказ, СтрокаДвижения.Имя);
               ВызватьИсключение "Операция не выполнена";
           КонецПопытки;
       КонецЕсли;    
   КонецЦикла;
   
   ОчисткаКоллекцииДвиженийДокумента(ДокументОбъект);
   
   // Удаление записей регистрации из всех последовательностей
   УдалитьРегистрациюДокументаВПоследовательностях(ДокументОбъект, Истина);

КонецПроцедуры

(84) Автоматические это всегда блокирование в SQL диапазона записей. Управляемые это блокирование отдельных записей. Если происходит scan, то все просмотренные записи так же блокируются.

(87) Почему бы перед удалением движений не объединить в таблицу записи по движениям и Табличной частью?

Прошу прощения (87) это к (83)

(86) давай с автоматическими разберемся сначала. Они ведь блокируют диапазоны значений по индексированным полям. Так? Если диапазоны не пересекаются, то почему у автора проблемы с блокировкой?

(87) Извини, не понял, что с чем объединить? И что от этого изменится?

2) Ставим управляемые блокировки на наборы записей регистров по регистратору (хотя толку от этого нет);

Объединяем Движения с табличной часть. При этом у нас будет 1 запрос на блокировку вместо двух. Хотя возможно это большой роли и не играет.

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

(89) Если бы автоматические блокировали только нужные диапазоны, необходимости в управляемых не было бы.
Упрощенно, допустим у нас 5 номенклатур, Н1, Н2, Н3, Н4, Н5. Есть таблица с индексом по номенклатуре. В запросе мы считываем данные по номенклатуре Н2 и Н4. При SERIALIZABLE (автоматические) заблокируются записи Н2, Н3, Н4. При REPEATABLE READ (управляемые) Н2 и Н4.

(93) и это видимо объяснение того, почему (92) - оптимальный вариант? В том смысле, что не надо ставить искусственные блокировки на измерения без индексов, чтоб не заблокировать лишнее. А индексированные измерения будут блокироваться только те, что нужно. Так?

(92) а может там где-нибудь всё же затесалась автоматическая блокировка? Например, из документа, а не из регистра.

(4) Да в основной массе так, но если мы сначала записываем данные, а потом считываем, можем натолкнуться на deadlock. В таком случае правильнее будет заранее заблокировать необходимые записи с использовнием БлокировкиДанных, но нужно помнить, что не всегда считывается только то, что необходимо.

(96) к (94)

(96) ясно, спасибо.

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

(99) Гоню, на копии просто отключено списание по партиям, значит вопрос не снят.

Рыжий Лис, а можно определить - происходит ли scan table при выполнении запроса к регистру партий? Потому что вторая транзакция стоит на запросе, получающем остатки по партиям, хотя фильтры там стоят. Т.е. можно сделать вывод, что либо при удалении набора записей блокируется полностью таблица регистра (что навряд ли), либо что при выполнении запроса к регистру партий на получение остатков, происходит скан таблицы. Я правильно понимаю?

(93)
"При REPEATABLE READ (управляемые) Н2 и Н4."  

В управляемом режиме уровень изоляции READ COMMITED

если что

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

Подниму интересную темку...

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

(104)
Слей базу или ЦФ на яндекс народный диск
или опиши как воспроизвести ситуацию

Ссылку на яндекс можно в почту

(104) Базу не могу, посодют ))), сейчас опишу ситуацию

(107) если цф, то вроде как не за что сажать...

(107)
ЦФник можешь на яндекс залить?

(109)
Сейчас позвоню, узнаю, там просто доработок их программистов куча, я приходящий, могут высказать кучу нехорошего, сейчас подождите, пожалуйста!

дали добро, сейчас залью

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

(112)
это мы уж как нибудь решим

http://narod.ru/disk/23994303000/1Cv8.cf.html - вот ссылка

(114) Работаю пока только с Реализацией.

Что удалось выяснить:
1) Если в одном документе в таб.части есть пересекающиеся по номенклатуре и серии элементы, то независимо от склада, не проводится.
2) Попадаются документы, с непересекающейся номенклатурой, но блокировка происходит (бывает очень редко).

В ЦУПЕ посмотрел, аналогичная задача на УПП последней (параллельное перепроведение двух потоков реализаций) с упр.блокировками:
1. Блокируется регистр РасчетыПоРеализации (поставил два счетчика блокировки СУБД и 1С-ные), блокирует СУБД.
2. При начале проведения идет отмена всех движений документа (ОбщегоНазначения.УдалитьДвиженияРегистратора)
3. Отмена движений идет без наложения управляемых блокировок.
4. При добавлении движений упр.блокировки конечно-же есть.
5. После заремливания УдаленияДвижений все блокировки исчезли.
Вывод: движения на корректность не проверялись, но но блокировка идет серверная несмотря на управляемость.
P.S. в торговле 11 от этого избавились

(115)
3) Есть некоторые документы, которые проводятся с пересекающейся номенклатурой и серией и разными складами.

(116) А в 11 как избавились?

удаления нет, есть загрузка

Таблица= ДополнительныеСвойства.ТаблицыДляДвижений.ТаблицаТоварыНаСкладах;
   
   Если Отказ ИЛИ Таблица.Количество() = 0 Тогда
       Возврат;
   КонецЕсли;

   Движения.ТоварыНаСкладах.Записывать = Истина;
   Движения.ТоварыНаСкладах.Загрузить(Таблица);

(119) Ясно

Решение проблемы

В процедуре УдалитьДвиженияРегистратора

Закоментировать следующий код

           Попытка
               СтрокаДвижения.НаборЗаписей.Записать();
           Исключение
               // возможно «сработал» RLS или механизм даты запрета изменения
               СообщитьОбОшибке(ОписаниеОшибки(), Отказ, СтрокаДвижения.Имя);
               ВызватьИсключение "Операция не выполнена";
           КонецПопытки;

Этот кусок кода в общем то нафиг не нужен и особой ценности не предстваляет

Детально еще не разобрался но похоже проблема в операторе

"Попытка"

(122) Задвоение движений не фонтан,
      уберешь попытку 1С вылетит с ошибкой

(122) Мебиус, спасибо большое за помощь, а движения удалятся?

Где ты видишь задвоение движений? Движения очищаются в другом месте.  

Внимательно изучи процедуру удаления движений.

Данный кусок кода - не очень удачная перестраховчная заглушка проверки на RLS и дату запрета.
В общем и целом  нафиг не нужная.  

"1С вылетит с ошибкой"
В форточку что ли вылетит? )  

Кстати этот кусок чреват не только таймаутом но и дедлоком - уже сталкивался.

(124)
Все будет ОК.

Глянь процедуру. Та сначала идет попытка записи (то что мы комментируем)  а затем только в следующей очистка.

(126) Ок, спасибо большое, Мебиус, как проверю, отпишусь о результате.

(127)
И еще

Проверил

Проблема именно в операторе "Попытка"

Для стерильности лучше закомментировать только его

   Для Каждого СтрокаДвижения ИЗ МассивОбрабатываемыхСтрокТаблицыДвижений Цикл        
       Если СтрокаДвижения.БезусловноеУдаление Тогда
           ПолныеПрава.ЗаписатьНаборЗаписейНаСервере(СтрокаДвижения.НаборЗаписей, ДокументОбъект.Ссылка);
       Иначе        
           //Попытка
               СтрокаДвижения.НаборЗаписей.Записать();
           //Исключение
               //// возможно «сработал» RLS или механизм даты запрета изменения
               //СообщитьОбОшибке(ОписаниеОшибки(), Отказ, СтрокаДвижения.Имя);
               //ВызватьИсключение "Операция не выполнена";
           //КонецПопытки;
       КонецЕсли;    
   КонецЦикла;

(122) а теперь расскажи как ты к этому пришел. Как именно тестировал и что проверял. Бо метод ценнее решения...

(129) +100500

Не, комментировать запись набора нельзя. Движения очищаются, а записи в регистрах остаются, поэтому закомментил только попытку. )

(129)
А чего рассказывать

Првая мысль
Поведение для платформы не нормальное так как в управлемом режиме уровень изоляции транзакции READ COMMITED, что по идее должно исключать подобную ситуацию. Если только  не идет явного повышеня уровня изоляции вроде инструкции "ДЛЯ ИЗМЕНЕНИЯ. Такого там нет - следовательно есть аномалия.    


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

Дальше копать - нужно анализировать блокировки СУБД SQL.

(132) ясно, спасибо.

(131)
И что с того что они остаются. Кстати в исходном варианте они тоже ОСТАЮТСЯ.
Этот кусок кода только проверяет - не пытаешься ли ты удалить то что не положено.

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

(134) Насколько я понимаю, коллекция движений записывается в таблицы базы с окончанием проведения. А тут происходит насильственная запись пустого набора уже в этот момент. Разве это не может быть критичным, если алгоритмы дальнейшего проведения после этой очистки движений далают запрос к состоянию регистра?

(134) А ты закомментируй эту строку, и попробуй отменить проведение какого-нибудь документа, и посмотри Движение документа по регистрам - все движения остаются. И сделай то же самое, но без комментирования строки - движений нет.

(135) (136)

Ну да есть такое дело - не внимательно посмотрел

(136)
Комметарий "Попытки"  помог?

(138) Сейчас буду тестировать.

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

(140) конечно интересно. Излагай.

(140) Очень интересно, ну вроде, Мебиус не хамил )

1. При обработке проведения открывается транзакция, которая висит до конца проведения.
2. Все изменения данных и в том числе удаление висят до конца.
3. Так как управляемая блокировка не ставиться при удалении, то данные блокируются
на сервере СУБД.
4. При проведении второго документа возникает взаимоблокировка между удаляемыми данными первого документа и добавлением данных во-втором документе на СУБД.
5. А так как некоторые регистры сведений не индексируемы для быстроты добавления данных, то они блокируют почти всю таблицу.
Вывод: создавать документы можно параллельно, а удалять по одному.

и ставь "попытку" или не ставь СУБД на нее очень глубоко

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

(143)
"При проведении второго документа возникает взаимоблокировка между удаляемыми данными первого документа и добавлением данных во-втором документе на СУБД. "

ну и где мы здесь наблюдаем дедлок?

"1. При обработке проведения открывается транзакция, которая висит до конца проведения."

Это вероятно повышение уровня изоляции?

(143) Да, и как индексы влияют на блокировки СУБД? Тут вообще непонятно, потому что, как ни странно, после удаления индексов в регистре сведений "Списанные товары" регистр перестал блокироваться, но зато после добавления индекса в регистр партий тоже повысилась параллельность?

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

Так что там с "Попыткой"  ?

(145) 1С все тестирования проводит на создание документов, не видел ни одной ссылки на сайты 1С где данные удаляются и все в ажуре

(151) есть еще перепроведние документа, тоже вызывающее очистку движений

(150) Не, Мебиус, та же кухня. Неясно, что там блокируется, потому что некоторые документы проводятся с разными складами и пересекающейся номенклатурой и серией, а некоторые не проводятся (

(146) могу картинку из ЦУПА вставить, но не знаю как

(148) на этот вопрос надо целую лекцию прочитать

(153)

Не знаю
У меня два одинаковых документа с одинаковой номенклатурой и складом
и все проводится

Ты именно попытку закоментировал

(154) smages.com radikal.ru

(155) эт хорошо. Люблю слушать лекции. ;)

(156) Да. Вот и у меня некоторые проводятся, а некоторые нет.

(155) А есть лекция? )

(153)
Странно, у меня тоже теперь не проводится хотя 5 мин назад проводилось.

(161) Во-во, полтергейст какой-то )

(162)
У тебя доступ на партнерский есть?

Да, есть

Нужно Константину месседж писать
Пускай скажут что к чему

Как успехи автора?

интересная тематика, еще одна причина корректировки данных, а не их удаления

(143) Интересно это при присутствии измерений не индексируются?
уникальный _SimpleKey все равно присутствует.

(166) Все по-старому пока, сейчас вот решил на 8.2 поставить базу, посмотрю, будут ли различия, если нет, то наверное, придется менять алгоритм проведения.