Как работают управляемые блокировки

29.04.19

База данных - HighLoad оптимизация

Все типовые конфигурации содержат ошибки, потому как управляемые блокировки в 1С слишком уж "управляемые", при понижении уровня изоляции про некоторые "нюансы" просто забыли. Для создания и эксплуатации качественной системы, которая способна поддерживать транзакционную целостность данных при параллельной работе, информацию в этой статье желательно знать, хотя, конечно, ничего особо нового я не открыл.

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

Итак начнём - простой кейс:

Конфигурация 2 объекта РС и Документ.

Конфигурация

Регистр сведений независимый, код следующий:

Блок кода 1

	Если Блокировать Тогда		
		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();
	КонецЕсли;
	
	Если ЧитатьЗапросом Тогда		
		Запрос = Новый  запрос();
		Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
		ТЗ = Запрос.Выполнить().Выгрузить();
	КонецЕсли;

	Если ЧитатьНабор Тогда		
		Набор = РегистрыСведений.РегистрСведений1.СоздатьНаборЗаписей();
		Набор.Прочитать();
	КонецЕсли;

	Если ЗаписатьНабор Тогда		
		Запись = набор.Добавить();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес = 3;	
		Набор.Записать();
	КонецЕсли;

Всё предельно просто.

Теперь Запускаем два сеанса.

Сеанс 1: Проводим документ с галкой "Блокировать". Ставим точку останова на строке:

"Если ЧитатьЗапросом Тогда".

Сеанс 2: Проводим документ с галкой "Читать запросом". 

Внимание вопрос: "Проведётся ли документ во втором сеансе или нет?"

Нам бы очень хотелось чтобы ответ на данный вопрос был "нет".

Тем не менее, документ проводится - без особых проблем.

 

Повторяем эксперимент - только во втором сеансе ставим галку "чтение набора"

Тот же вопрос "Проведётся?"

Очевидный ответ - "Конечно", ведь по сути что там что там чтение всего регистра.

Тем не менее наблюдаем примерно следующую историю: 

Конфликт блокировок

Таким образом, объектное чтение и чтение запросом работает по-разному. На мой взгляд, это в корне неправильно. При этом объектное чтение, очевидно, учитывает управляемые блокировки, а чтение запросом - ни коим образом.

Спойлер - эти тесты проводим пока в режиме "клиент-сервер".

Из эксперимента выше сделаем несколько первых выводов:

Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.

Вывод 2: Объектное чтение и чтение запросом работает по разному

 

Тут можно сказать: "здравствуй фантомное чтение, неповторяющееся чтение". От "Грязного чтения" нас убережет MS SQL: в уровне изоляции READ COMMITED SNAPSHOT "грязное чтение" невозможно. Хотя я тоже сомневаюсь, потому как объектная модель 1С не полностью отражается в СУБД возможно могут быть нюансы, но примеров подобрать пока не удаётся.

 

Для того, чтобы понять на каком этапе своего развития в платформе 1С потеряли требование "согласованности данных" обратимся к истории.

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

 

Блок кода 2

	Запрос = Новый Запрос;
	Запрос.Текст = "ВЫБРАТЬ
	               |	СУММА(РегистрСведений1.Рес) КАК Рес
	               |ИЗ
	               |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1
	               |
	               |ДЛЯ ИЗМЕНЕНИЯ";
	Выборка = запрос.Выполнить().Выбрать();
	Выборка.Следующий();
	Количество = Выборка.Рес;
	
	
	
	Если Количество > 0 Тогда
		
		Запись = РегистрыСведений.РегистрСведений1.СоздатьМенеджерЗаписи();
		Запись.Изм = Строка(Новый УникальныйИдентификатор());
		Запись.Рес  = -1;
		Запись.Записать();
			
	КонецЕсли;

 

Я специально избегаю регистров накопления в примерах, потому как в РН как минимум две таблицы на уровне СУБД, а хочется продемонстрировать на одной.

Этот код выполняется в транзакции - в обработке проведения документа в моём случае. Первую транзакцию нужно конечно остановить и попытаться провести вторую. По условию мы не должны уйти в минус.

 

1С 8.1  и ранее (ну или просто Автоматический режим блокировки)   

второй документ "висит на блокировке". После прохождения точки останова второй документ проводится, запись в РС не создаётся.

Код отрабатывает правильно как в случае остановки "после записи" так и в случае "после чтения".

Секрет конечно в инструкции "для изменения", которая кроме всего прочего превращает S блокировку в U.

На уровне СУБД уровень изоляции MS SQL - SERIALIZABLE. MS SQL блокирует всё что надо и не надо. Чтобы получить несогласованные данные  надо очень постараться.

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

 

1С 8.2 и первые версии 8.3 (режим управляемых блокировок)

Появились "Управляемые блокировки". Самое главное что происходит с MS SQL при установке "управляемой блокировки" - уровень изоляции становится "READ COMMITED". 

Чтобы включить его в последних редакциях 8.3 нужно выполнить:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT OFF
GO

Здесь уже немного похуже. Если точку останова в коде поставить после записи - всё отработает как и в предыдущем примере - транзакция установит X блокировку и всё будет OK. А вот если точку останова поставить после чтения - получим совместимые S блокировки - одна и та же информация будет считана двумя транзакциями.

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

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

Конечно нужно добавить в этот код начало вроде:

		Блокировка = Новый БлокировкаДанных();
		Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
		Элемент.Режим = РежимБлокировкиДанных.Исключительный;
		Блокировка.Заблокировать();

и нам уже ничего не страшно.

Зачем я тогда делаю на этом акцент?

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

Но если у вас в транзакции происходит чтение элемента справочника, который в данный момент может изменять другая транзакция?

Вот тут как раз S блокировка очень сильно пригодилась бы. Но об этом дальше.

 

Современные версии 1С 8.3

Возвращаем обратно режим версионника:

ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION ON
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT ON
GO

Выполняем код - получаем "-1" как в случае установки "точки останова" при чтении, так и в случае установки "точки останова" при записи.

Теперь можно сделать ещё один вывод:

Вывод 3: чем современнее версия 1С, тем больше возможности для параллельной работы и тем меньше шансов обеспечить согласованность данных.

 

А теперь "Гвоздь программы": файловая база - код приведенный в блоке кода 1 выполняем в ней. Единственное изменение - код чтения данных из регистра придётся перенести в обработку, т.к. в файловой базе два одинаковых документа параллельно провести не получится.

В обработке будет код:

      НачатьТранзакцию();
	  	 	Запрос = Новый  запрос();
			Запрос.Текст = "ВЫБРАТЬ
	            	   |	РегистрСведений1.Рес КАК Рес
	        	       |ИЗ
	    	           |	РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
			ТЗ = Запрос.Выполнить().Выгрузить();
	  ЗафиксироватьТранзакцию();

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

Убираем галку "блокировать" в документе (но не точку останова) конечно без проблем читает регистр.

Итак, в завершение "чудес" управляемых блокировок получаем их разную работу в файловой и клиент-серверной версии.

Вывод 4: Управляемые блокировки в файловой и клиент-серверной версиях работают по-разному. В файловой - "нормально".

 

Теперь о косяках в типовых. Для примера возьму УТ 11.

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

Так вот, "косяк" потенциально будет во всех строчках этого запроса где "точка" фигурирует дважды:

"КОГДА ЕСТЬNULL(ТаблицаТовары.Назначение.ДвиженияПоСкладскимРегистрам, ЛОЖЬ)"

"И (НЕ ТаблицаТовары.Склад.ИспользоватьОрдернуюСхемуПриОтгрузке

И ТаблицаТовары.Номенклатура.ТипНоменклатуры В"

Что в этом плохого? 

Ну вот представьте - начали вы проведение документа пока склад ещё был не ордерным, а в процессе проведения кто-то его поменял на ордерный...

Или тип номенклатуры сменил с "товара" на "услугу". Он это сможет влёгкую сделать. А вы потом не сможете доказать что "когда я нажимал кнопку всё было хорошо". Все проверки, включая конечно "обработку проверки заполнения" документ пройдёт ещё до изменения данных. 

Кроме того - есть прекрасная возможность в один регистр записать данные исходя из информации что склад ордерный, а в другой - нет, и всё это в одной транзакции. Это и есть так называемое "фантомное чтение", которое, как мы помним, для "READ COMMITED SNAPSHOT" вполне возможно. 

Наверное не нужно лишний раз писать что найти и устранить подобные ошибки очень и очень сложно. Ещё труднее понять что же являлось причиной подобного поведения системы.

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

Процедура ПередЗаписью(Отказ)

	Если ОбменДанными.Загрузка Тогда
		Возврат;
	КонецЕсли;

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

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

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

Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении

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

Почему на это не особенно обращают внимание? Да потому что эти ошибки видны только в случае реальной параллельной работы большого количества пользователей, да и то крайне редки. Если у вас много пользователей в базе 1С, у вас скорее всего наберётся несколько куч проблем более актуальных, чем описанный выше кейс. Ну а у кого всё хорошо и все вопросы решены скорее всего уже правильно расставлены блокировки, и такие крупные компании редко работают на типовых базах. Но вообще знать о таком "поведении" платформы нужно, как и учитывать его в проектах, которые ориентированы на большое количество параллельно работающих пользователей. Ведь пока мы (1С-ники) не научимся корректно работать с системами, в которых 1000+ активных пользователей и обеспечивать в них согласованность данных SAP нам на рынке не подвинуть. 

P.S. Всё описанное выше "не баг а фича", вполне нормально документировано на ИТС, который всё равно никто не читает  на котором вы можете детально ознакомиться с описанием работы управляемых блокировок "от Вендора" https://its.1c.ru/db/v8314doc#bookmark:dev:TI000000535 

P.P.S. Если это прочитают коллеги из 1С - тут нет "камня в огород типовых" или в сторону реализации управляемых блокировок (хотя конечно хм...). Из статьи выше должно по задумке стать очевидным, что прикладным разработчикам очень не хватает возможности выбирать уровень изоляции с которым будет начинаться транзакция (в т.ч. неявная). READ COMMITED для проведения документов списания товара это слишком лайтово. Всех косяков, с этим связанных, не выловить.
 

Управляемые блокировки

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2973    spyke    26    

42

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5106    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7633    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5976    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8865    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

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

15.11.2023    5105    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16181    skovpin_sa    14    

98
Отзывы
177. kolya_tlt 08.05.19 15:53 Сейчас в теме
Люто плюсую по выводу №5. Но моя практика показала, что платформа просто не справляется с таким количеством блокировок. Сервер 1С просто ложился каждые два часа. Кейс был абсолютно такой же - движения документа зависели от галок номенклатуры и мы блокировали ссылки номенклатур документа, который проводится. Пришлось от этой идеи отказаться :(
acanta; comol; +2 Ответить
165. alex_sh2008 4 07.05.19 18:35 Сейчас в теме
(164)Уровни изоляции уже есть в скл сервере, в 1С достаточно просто транслировать объектные блокировки на реляционную базу, а то что сейчас сделали мне вообще не понятно.
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. w.r. 643 29.04.19 19:50 Сейчас в теме
15. starik-2005 3033 30.04.19 10:44 Сейчас в теме
16. comol 5051 30.04.19 11:28 Сейчас в теме
(1) Правильная и хорошая статья. То о чём я пишу в своей на ИТС конечно не напишут. Вернее инфу можно найти и на ИТС, мелким шрифтом в разных местах, не в базовой статье конечно
37. w.r. 643 30.04.19 20:23 Сейчас в теме
(16)

К слову, про файловые и клиент серверные версии, есть такая табличка с сайта 1С, которая абсолютно все объясняет

39. comol 5051 30.04.19 22:29 Сейчас в теме
(37)
которая абсолютно все объясняет

Как бы мне хотелось чтобы это было так.
Конечно она не объясняет почему управляемые блокировки - пусть даже не всю таблицу в файловой и клиент серверной версии работают по-разному
41. acanta 30.04.19 22:31 Сейчас в теме
(37) эта табличка показывает как правильно называется составляющие технического решения Сама проблема в применении к 1с в том, что специалист по sap (например) при переходе с 1с на что то другое имеет и квалификацию и полномочия и возможность прямого доступа к данным при помощи СУБД не используя ни код ни платформу ни лицензии 1с.
Достаточно описания структуры метаданных.
А 1с ник при такой работе с данными чего то нарушает, а без соответствующего сертификата ещё и не имеет необходимой квалификации.
"либо крестик снимите либо трусы наденьте."
38. w.r. 643 30.04.19 20:26 Сейчас в теме
(16)

И ещё вопрос - зачем для чтения (ЧитатьЗапросом) используете исключительную блокировку, а не разделяемую
40. comol 5051 30.04.19 22:30 Сейчас в теме
(38) Ну для контроля остатков должна быть исключительная... А то ведь кто-то ещё прочитает
45. w.r. 643 30.04.19 23:10 Сейчас в теме
(40)

Это только мое предположение, но мне кажется, что дело здесь в объекте НаборЗаписей. Платформа его интерпретирует как объект, производящий запись данных (даже только при чтении набора) и работает с ним не так, как с объектом Запрос. Я бы обратился с этим вопросом в поддержку фирмы 1С ради интереса
48. comol 5051 30.04.19 23:35 Сейчас в теме
(45) Всё так. И это будет официальная позиция 1С. Но суть в том что чтобы правильно наложить все блокировки при чтении запросом нужно или выполнить его дважды или полноценно разбирать, а это уже сделать из 1С сервер СУБД по сути :)
49. acanta 01.05.19 08:53 Сейчас в теме
(48) Ни менеджер среднего звена ни бухгалтер с екселем и выгрузкой из СУБД тоже в этом комбайне не нуждаются. А для операторов достаточно любой (той же веб надстройки над любой СУБД) для формирования и распечатки первички.
И тогда все те же блокировки возникают на уровне коммуникации между людьми и решаются так же.
Если есть проблемы с коммуникациями, то полноценно заменить их при помощи 1с не получится.
И если за 20 лет существования 1с проблема параллельной работы с контролем остатков не решена до сих пор, значит на нее нет спроса в данном сегменте.
А те сегменты где такая потребность есть уже давно заняты.
50. comol 5051 01.05.19 12:49 Сейчас в теме
(49)
А те сегменты где такая потребность есть уже давно заняты

И будут заняты другими пока проблема не будет решена :)
51. starik-2005 3033 01.05.19 15:06 Сейчас в теме
(49) проблема решается тем, что остатки контролируются после записи движений. И тот документ, при проведении которого зарегистрирован минус, просто отменяет транзакцию. Это сложно понять современным 1С-никам, но, с другой стороны, и не надо - без них разберутся.
SuhoffGV; Maito; jONES1979; Akvals; vano-ekt; chernov.gigansk.ru; zakiap; acanta; +8 Ответить
52. acanta 01.05.19 15:10 Сейчас в теме
(51) зарегистрирован минус на когда?
При одновременном проведении двух документов с одинаковым временем запрос это вообще может определить?
53. starik-2005 3033 01.05.19 15:55 Сейчас в теме
(52) ну у обоих пользователей документ не проведется, что такого? Фактически две транзакции. В первой остаток меняется, во второй меняется, вот первая транзакция записывает регистр, в это время в модуле регистра срабатывает событие "при записи", там читается остаток по отбору из записанного уже набора записей и проверяется, есть ли минус. Если есть - отказ. То же самое во втором документе. Если у обоих внезапно стал минус - ну оба отвалятся и потом кто-то снова проведет документ.

Сам SQL (если говорить о СУБД) не пишет данные одновременно - он одновременно в очередь поместить может. А пишет отдельный поток.

ЗЫ: Вообще в компьютере нет ничего "одновременного" в плане записи на один диск. И для целостности софт делает sync, чтобы быть уверенным в изменениях. А вот при чтении мы можем что-то взять из кеша дважды, но, опять же, кеш обнолвляется при записи, которая не одновременна. Такой вот "парадокс".
54. acanta 01.05.19 16:16 Сейчас в теме
(53)Вы меня простите, не хочу никого обидеть. Но вот есть два спринтера. Они пересекают финиш и срывают ленточку одновременно. Приз достанется кому то одному, что тут такого.
Но журнал регистрации отключен в конфигураторе, а запросы к журналу транзакций превратили бы 1с в СУБД, а если учитывать файловую систему с кэшами и буферами то и в ось..
И вот уже программист 1с заводит регистр сведений и прописывает очередь проведения с учётом приоритета пользователей по своему усмотрению.
Сначала проводить все документы Тани, затем Васи и и только потом МарьИвановны. И все они на процентах.
59. starik-2005 3033 01.05.19 20:53 Сейчас в теме
(54) ну вот пересекают они финишь, но один оказался в очереди раньше - никуда не деться. И второй при записи регистра упирается в Х-блокировку ресурса уже на сервере SQL и будет ждать. Если регистры во всех документах записываются в одной последовательности, то дедлока не будет - будет простая очередь ожидания. Именно для этого в свое время придумали механизм записи регистров при записи документа - там последовательность строго блюдется. А еще в УПП лет сто назад (в 8.1) контроль регистра остатков был сделан в модуле набора записей этого регистра. И ничего не тормозило у товарищей с нормальной техникой, и никогда (ни разу) не было никаких случайных отрицательных остатков. Читайте "библию разработчика 1С" - там это уже лет надцать как описано. А то, что себе придумывают люди - это от незнания.
55. alex_sh2008 4 01.05.19 18:17 Сейчас в теме
(51) С таким подходом производительность вашего приложения упадет в разы на больших нагрузках
46. SanchoD 295 30.04.19 23:22 Сейчас в теме
(40) Сейчас в тренде новый подход к проведению. Сначала проводим документ as is. А потом снимаем остатки на регистрах. Вышли в минус - откатываем транзакцию.
Maito; zakiap; w.r.; acanta; +4 Ответить
47. comol 5051 30.04.19 23:34 Сейчас в теме
(46) "Сейчас" это лет 5 или 6 вроде? :)). Но суть дела не меняет - всё равно надо накладывать исключительную блокировку.
56. alex_sh2008 4 01.05.19 18:19 Сейчас в теме
(47)Не только исключительную но и уменьшать количество записей в одной транзакции, лучше сделать несколько последовательных транзакции ,1 строка 1 транзакция , чем 1 транзакцию для записи 100 строк.
57. acanta 01.05.19 18:43 Сейчас в теме
(56) даже в этом случае документ или справочник с табличными частями при изменении или добавлении строки будет записан целиком. Или нет?
58. alex_sh2008 4 01.05.19 19:33 Сейчас в теме
(57) На ваши транзакции наложится еще главная транзакция на весь документ или справочник. Поэтому все эти танцы с бубнами просто пустая затея. Не забывайте есть транзакция 1С и транзакция сервера базы данных, это разные вещи, если вы делаете блокировку в коде 1С это во все не означает что эта блокировка происходит на sql сервере, блокировки на скл сервере включаются только тогда когда действительно происходит запись/чтение данных самой 1С. Чем быстрее будет выполнен код 1С в транзакции тем меньше будет блокировок.

Если хотите добиться максимальной параллельности выполнения транзакций:
1. максимально исключите использование табличных частей у документов и справочников.
2. Используйте минимум транзакций в своем коде, включайте транзакции только тогда когда это действительно необходимо.
3. Не выполняете в транзакции какие либо емкие операции
4. проверяйте остатки и другие параметры не во время записи данных, а во время подготовки данных перед записью, до начала основной транзакции записи данных. Например во время редактирования данных в табличной части документа.
creatermc; Aleskey_K; zakiap; acanta; +4 Ответить
61. acanta 01.05.19 22:54 Сейчас в теме
(58) не понимаю, вы хотите сказать что блокировка сервера 1с накладывается на объект метаданных 1с (например документ или справочник с табличными частями, но без подчинённых справочников или записей регистра сведений)
62. alex_sh2008 4 01.05.19 22:59 Сейчас в теме
(61)Ну да, за исключением документов, все движения тоже по падают в транзакцию и блокируются (в зависимости от режима записи/чтения)
60. comol 5051 01.05.19 22:49 Сейчас в теме
(56)
лучше сделать несколько последовательных транзакции ,1 строка 1 транзакция , чем 1 транзакцию для записи 100 строк

лучше конечно... но согласованность данных при такой истории обеспечить намного сложнее.
63. alex_sh2008 4 01.05.19 23:03 Сейчас в теме
(60)Это вопрос планирования архитектуры приложения и методик разработки. Много конечно из 1С не выжать но что то можно.
2. Evil Beaver 8107 29.04.19 20:23 Сейчас в теме
Читал-читал, а все свелось к тому что "блокируйте все, что надо и не блокируйте то, чего не надо"...

В свое время управляемые блокировки мне коллега объяснил, как мьютекс. Блокировка это мьютекс. Обьектное чтение захватывает его автоматом, а запрос - нет. Вот и все объяснение.

А писать параллельный код правильно - да сложно, и без косяков никак. Тут Олег прав :)
17. comol 5051 30.04.19 11:30 Сейчас в теме
(2) свелось к тому что "блокируйте всё что надо, само не заблокируется за вас" :).
Технически там наверное всё-таки не мьютекс.... надо доп. инфу хранить и между серверами синхронизировать.
в SQL захватывается автоматом, а в 1С этого не стали делать... я думаю просто потому что очень сложно реализовать технологически.
197. Evil Beaver 8107 12.05.19 19:34 Сейчас в теме
(17) "Мьютекс" - это абстрактно, чтобы было проще объяснить принцип: захватил/отпустил. А что там внутри - это один БГ ведает.
3. RustIG 1351 29.04.19 21:38 Сейчас в теме
(0) интересная работа!
то, что система несовершенна - стало очевидным.

а если абстрагироваться от названий "автоматический" и "управляемый", можно ли огласить (описать) алгоритм "на пальцах" - как должна вести себя блокировка записей таблиц при параллельной работе пользователей?
(желательно на примере) есть у кого красивая идея?
18. comol 5051 30.04.19 11:30 Сейчас в теме
4. RustIG 1351 29.04.19 21:43 Сейчас в теме
(0) в 8.1 (на обычных формах) всегда была возможность программировать свою функциональность по блокировкам - то есть в каждом конкретном случае разработчику приходилось прорабатывать механизм и тестировать все варианты "идеальной" параллельной работы самим, не надеясь на встроенный механизм автоматич. блокировок.
как сейчас усложнилась технология на управляемых формах - не знаю. наверное, усложнилась...
5. bulpi 215 29.04.19 23:11 Сейчас в теме
Я знал! Я предполагал! Я чувствовал! Автор молодец, грамотно изложил мои подсознательные подозрения :)
6. par_62 30.04.19 06:46 Сейчас в теме
Нет программ,в которых " и рыбку съесть и ... ( по тексту)". Обычно оценивается вероятность тех или иных событий. Вероятность изменения неордерного склада на ордерный - минимальна в процессе работы и обычно выполняется только специалистом учета или администратором системы. Если это нет - вопрос к организаторам учета на предпииятии и к специалистам внедрения.
vdscom; Alias; +2 Ответить
19. comol 5051 30.04.19 11:32 Сейчас в теме
(6) всё так конечно... просто задача хорошей ИС обеспечить согласованность данных при любой ситуации...
7. Kami4 30.04.19 07:21 Сейчас в теме
Возьму на заметку, всё подробно и с полным анализом!
8. RustIG 1351 30.04.19 07:33 Сейчас в теме
На мой взгляд, проблема блокировок заключается в том, что пока не закончилась транзакция операции, кто-то пытается изменить что-то связанное с данной операцией. Чем длительнее транзакция, тем более вероятно, что будут блокировки.
Отсюда рекомендация - сократить транзакции по времени.
К примеру, при проведении документа запускаются 10 проверок, сведения записываются поочередно в разные 10 регистров накоплений, и все это в одной транзакции. Возможно, стоит попробовать отделить какой-то регистр , и записывать в него в отдельной транзакции - в другом месте и в другое время....
В свое время я доработал отправку счетов по электронке - создал кнопку - так в период массовых рассылок - когда три бухгалтера отправляют в течение часа по 20 писем - стали возникать блокировки... Когда письмо уходит через электронную почту - транзакция по времени становится длительной - ждем ответа от электронки - ушло письмо или нет, чтобы изменить статус письма в 1С...
Тогда я создал регистр сведений "Очередь отправки писем". Блокировки исчезли, поскольку письма вставали в очередь мгновенно, а отправкой занимался робот в фоновом режиме...Делал на платформе 8.1 на БП 1.6 лет 5 назад. До сих пор работают по этой схеме.
В дальнейшем в УТ 11 перешли на расчет себестоимости при проведении реализации в отдельной транзакции - в другом месте и в другое время. Так они сократили время транзакции проведения реализации, и уменьшили вероятность возникновения блокировок.
9. nvv1970 30.04.19 07:54 Сейчас в теме
Олег, может объясните что делает флаг ALLOW_SNAPSHOT_ISOLATION? К чему этот привет из прошлого?
1с его сто лет как не использует для переключения снепшотов. А msdn как-то не до конца понятно это объясняет. Например, здесь достаточно подробно (хотя это и не документация) https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server. Однако, snapshot и rcsi - это два разных уровня изоляции, а речь вроде как об уровне snapshot.
20. comol 5051 30.04.19 11:42 Сейчас в теме
(9) Ну насколько я помню этот флаг включает версионник для базы в MS SQL. Без него read commiten snapshot не включите.
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
В статье речи об уровне изоляции snapshot нет - везде конечно read commiten snapshot. Сам уровень изоляции snapshot прокомментировать не могу - не разбирался. 1С его не использует.
24. nvv1970 30.04.19 12:00 Сейчас в теме
(20)
В статье речи об уровне изоляции snapshot нет - везде конечно read commited snapshot. Сам уровень изоляции snapshot прокомментировать не могу - не разбирался. 1С его не использует.
Да, все верно. Snapshot будет тяжеловат для 1С. Не встречал, чтобы его использовали где-то... Поспрашиваю на sql.ru
Ну насколько я помню этот флаг включает версионник для базы в MS SQL. Без него read commiten snapshot не включите.
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
А вот тут - НЕТ.
Прикрепил файлик... Нигде, кроме master и msdb данный режим не используется. Это собственно два разных, режима. И на сколько я понимаю по различным описаниям на msdn - никак не пересекающихся. Один флаг отвечает за включение версионирования уровня RCSI, второй Snapshot. Думал, что вы, как человек бывалый, мне про это подробнее ответите )) Очевидно, что платформа первым флагом не оперирует. А рекомендация устанавливать два флага появилась с каких-то бородатых годов и сейчас вероятно не актуальна. SI появился кажется в 2005. И возможно там нужно было оба флага устанавливать.
Прикрепленные файлы:
25. comol 5051 30.04.19 12:06 Сейчас в теме
(24)
А рекомендация устанавливать два флага появилась с каких-то бородатых годов и сейчас вероятно не актуальна


Ну вообще 2017 год MSDN:

The following statements activate snapshot isolation and replace the default READ COMMITTED behavior with SNAPSHOT:

SQL

Копировать
ALT ER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

ALT ER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

Я не разработчик Micrisoft и даже не MVP по MS SQL, поэтому обычно следую документации если это работает.

А ещё я буду долго ржать если второй флаг без первого не работает и 1С по факту не использует версионность :)))))))))))))))
30. nvv1970 30.04.19 13:11 Сейчас в теме
(25) В документации же нет указания "нажимать все кнопки одновременно" )) Скорее трудности перевода.
Это два разных уровня изоляции. С разным поведением для чтения и модификации, с разными сценариями использования, с разной нагрузкой на tempdb. Достаточно погуглить Read committed Snapshot Isolation VS Snapshot Isolation
В общем случае MS не рекомендует использовать SNAPSHOT ISOLATION, а ограничиваться RSCI.

А то что флаг READ_COMMITTED_SNAPSHOT точно работает без ALLOW_SNAPSHOT_ISOLATION проверял лично еще на совместимости 8.2.16 - при равномерной нагрузке продуктовой базы поведение в части блокировок СУБД ну очень явно отличалось.
42. comol 5051 30.04.19 22:33 Сейчас в теме
(30)
А то что флаг READ_COMMITTED_SNAPSHOT точно работает без ALLOW_SNAPSHOT_ISOLATION

Ну верю... Не только у 1С есть косяки в документации

MS не рекомендует использовать SNAPSHOT ISOLATION

ХЗ что это такое. Его никто не использует

Скорее трудности перевода.
у меня всё норм с английским. По-другому перевести фразу "выполните эти инструкции SQL чтобы включить Read commited snapshot вместо Read commited" трудно.
198. Evil Beaver 8107 12.05.19 19:37 Сейчас в теме
(25)
и 1С по факту не использует версионность :)))))))))))))))


Использует. На ИС, по-моему, Андрей Бурмистров, показывал графики с разницей замеров между режимами.
10. frkbvfnjh 785 30.04.19 08:46 Сейчас в теме
Еще больше запутался с этими блокировками, теперь ваще не хочу программировать на 1С. Держать столько нюансов по работе с блокировками в голове, которые к тому же еще и меняю от платформы к платформе - это не нормально и не реально. Пока 1С определится как им нужно работать с блокировками пострадает много народу
acanta; wowik; +2 Ответить
11. RustIG 1351 30.04.19 09:24 Сейчас в теме
(10) волков бояться - в лес не ходить - и на первомайские шашлыки не ездить... :)
13. nvv1970 30.04.19 09:45 Сейчас в теме
(10) стоп-стоп.... никакой путаницы нету )))
Может автор немного сумбурно что-то изложил - так это только потому, что затронуты лишь отдельные специфические моменты, а не представлена вся система целиком.
В 1с нет ничего загадочного и нового, что есть в мире программирования, и все предельно просто.
Практически все лежит не в технической плоскости, а в плоскости логики и математики.
Что касается механизма управляемых блокировок, то он намного проще (на много порядков), чем блокировки СУБД (я вам не скажу за всю Одессу, а за MSSQL - скажу).

"пока создатели автомобилей не определятся куда водителям ехать - пострадает много народу"
Что это за.... ? ))) Как работать с блокировками - должна определиться не 1С, а автор программного кода, т.е. вы сами. По моему статьи про яблоки более чем достаточно. А детали поведения платформы (неявные управляемые блокировки) описаны в документации и немного в статье. Вы их должны знать. А наиболее очевидно и просто выяснить что генерирует блокировки, а что нет - посмотреть по техжурналу.
CSiER; Dach; comol; +3 Ответить
12. Dach 372 30.04.19 09:39 Сейчас в теме
Куда печальней, что нет нормальных инструментов, позволяющих с помощью менеджера 1с-ных блокировок посмотреть - какие блокировки наложены, на какие таблицы, кем и когда, с возможностью адекватного их завершения и т.д. Мониторить все это дело нечем, грубо говоря. И ТЖ тут тоже не особо помощник
SuhoffGV; babys; herfis; acanta; RustIG; comol; YPermitin; +7 Ответить
14. пользователь 30.04.19 10:44
(12)
ожностью адекватного их завершения и т.д. Мониторить все это дело нечем, грубо говоря. И ТЖ тут


А чем ТЖ не устроил в этом плане? Он фактически всегда дает ответы на вопросы:
- Кто поставил
- На что
- Сколько длится блокировка
- Причины конфликтов

С помощью ТЖ можно практически в реальном времени мониторить блокировки, если нужно. Такой опыт есть, даже где-то на ИС такое реализовывали. Но зачем? В нагруженных системах этот онлайн-мониторинг столько данных будет показывать, что стане бессмысленным.

Раскройте подробнее посыл, интересно узнать что еще нужно.
21. comol 5051 30.04.19 11:49 Сейчас в теме
(14) И умирает сервер если в ТЖ блокировки включить. А их надо бы как то фоново онлайн собирать - как MS SQL делает.
22. пользователь 30.04.19 11:55
(21) Смотря как настроить и что искать. :) Возможно конфигурация, когда влияние сбора ТЖ будет минимальным.

Но, согласен. У SQL Server инструменты гораздо лучше в этом плане.
23. comol 5051 30.04.19 11:59 Сейчас в теме
(22)
Смотря как настроить
Запись всех блокировок в текстовый файл... ну это убийство дисковой подсистемы при любом раскладе. ИМХО конечно, но у меня настроить так чтобы работало быстро не получается....
26. nvv1970 30.04.19 12:07 Сейчас в теме
(23) вы о упрблокировках 1с? Неожиданно... Если исключить <property name="Locks"> и хоть какого-то порог длительности установить, то все весьма компактненько...
27. comol 5051 30.04.19 12:08 Сейчас в теме
(26) а если установить порог и длительность смысл их вообще собирать? :)))))
YPermitin; +1 Ответить
28. пользователь 30.04.19 12:21
(27) обычно сбор ведь идет уже тогда, когда знаешь что ищешь.

Вообще, сбор массовый логов лучше изолировать от прода по максимуму. В этом случае отдельный диск или SSD. Анализ и разбор логов тоже на отдельном сервере.

Да что мы спорим :)
ТЖ это монстр, который надо готовить по необходимости)))

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

Если нужен прямо онлайн мониторинг, то пробовать отдельные диски и сервер для анализа данных с Эластиком!
31. comol 5051 30.04.19 14:18 Сейчас в теме
(28)
сбор ведь идет уже тогда, когда знаешь что ищешь

Сбор обычно идёт когда уже что то случилось и надо понять что...

Онлайн с ТЖ не получится... в Elastic тоже надо сначала выгрузить...
29. RustIG 1351 30.04.19 13:01 Сейчас в теме
(14) есть инструменты как консоль запросов, консоль заданий - открыл и мониторишь - вот такой инструмент нужен.
В сравнении с ТЖ - ТЖ перегруженный неудобный сложный. Консоль заданий - открыл и мониторишь...

Есть задачи и в не нагруженных системах - при которых было бы полезно мониторить блокировки. Да и потом в мониторе блокировок должен быть фильтр по объектам , которые мониторим...
YPermitin; +1 Ответить
36. пользователь 30.04.19 17:42
(29) (33) Поддерживаю.

Вот был бы аналог Extended Events, то жизнь стала бы проще.

Сейчас удавалось передавать асинхронно данные ТЖ в ElasticSearch с помощью утилиты на .NET Core (C#). Но событий было ограниченное количество, т.к. фильтры были установлены. Сам ТЖ за сутки набирал всего 2 ГБ. Что будет, если собирать все блокировки не могу сказать. Возможно, что передача данных в ES займет значительный объем ресурсов.
85. DonAlPatino 176 06.05.19 13:03 Сейчас в теме
(36) Отдельная статья с рассказом "как готовить ТЖ и ЕЛКу" будет?
86. пользователь 06.05.19 13:05
(85) а нужно?

В том плане, что об этом вроде и так много сказано. Даже на ИС был материал.
87. DonAlPatino 176 06.05.19 13:05 Сейчас в теме
(86) Пропустил видимо :-( Пошел искать...
88. пользователь 06.05.19 13:06
(87) не найдете - пишите. Что-нибудь придумаем :)
33. Dach 372 30.04.19 15:39 Сейчас в теме
(14) в том то и дело, что собирать с помощью ТЖ все блокировки 1с-ные - тяжко как для сервера, так и потом для анализа.

А хотелось бы вот что: ставишь в консоли администрирования "Пороговое время = N минут", показать все блокировки, которые висят дольше порога. Фильтр на таблицы метаданных тоже бы неплохо. Нет, может я чего-то не знаю и такое уже кто-то сделал? Просто у менеджера блокировок ведь есть эта информация! Он же как-то дает это понять другим сеансам, другим rphost ну и т.д.! Взаимодействие между процессами и т.д. и т.п. Просто дайте нам тоже посмотреть, вот и все. Хотя бы посмотреть
fd13; herfis; RustIG; YPermitin; +4 Ответить
32. PerlAmutor 129 30.04.19 14:55 Сейчас в теме
(0)

Если Блокировать Тогда
Блокировка = Новый БлокировкаДанных();
Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
Элемент.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
КонецЕсли;

Если ЧитатьЗапросом Тогда
Запрос = Новый запрос();
Запрос.Текст = "ВЫБРАТЬ
| РегистрСведений1.Рес КАК Рес
|ИЗ
| РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
ТЗ = Запрос.Выполнить().Выгрузить();
КонецЕсли;
Показать

Если после установки исключительной блокировки, таки прочитать что-нибудь из этого регистра сведений в той же транзакции. Блокировка на чтение сработает?
43. comol 5051 30.04.19 22:35 Сейчас в теме
(32)
той же транзакции
хоть заблокируйтесь и зачитайтесь :). Блокировка нужна для защиты от других транзакций.
66. PerlAmutor 129 03.05.19 06:09 Сейчас в теме
(43) Я о другом. В примерах, везде где ставится явная блокировка, впоследствии идет чтение данных и блокировка ставится на основании того, какие измерения были считаны. После этого в других транзакциях уже нельзя писать/читать те же измерения, что были заблокированы в первой транзакции. В статье идет установка блокировки, но, видимо, данные не читаются, так как для этого должны стоять две галочки одновременно и "Блокировать" и "ЧитатьЗапросом". Какая именно комбинация галочек установлена из статьи непонятно.
67. comol 5051 03.05.19 13:54 Сейчас в теме
(66) ничего не понял про галочки. В примере данные лочатся а потом читаются. Блокируется весь регистр потому что лень было делать более полноценный пример
68. PerlAmutor 129 03.05.19 15:23 Сейчас в теме
(67) Я сделал тестовую обработку, чтобы воспроизвести эффект, когда блокировка на чтение не ставится при явном задании исключительного варианта. Пробовал на 3 версиях платформы: 8.2, 8.3.7, 8.3.13. На трех конфигурациях ERP, ЗУП 2.5, БП2.0. Поведение везде одинаковое - регистр блокируется от чтения. Возможно дело именно в том, что если перед чтением данных не ставить никаких блокировок, то платформа даст это сделать, так как не будет выполняться попытка сравнения совместимости установленных блокировок (Исключительная+Никакая = Дает читать, Исключительная+Исключительная = Не дает читать) ?
Прикрепленные файлы:
ТестБлокировки.epf
69. comol 5051 03.05.19 18:42 Сейчас в теме
70. PerlAmutor 129 03.05.19 19:25 Сейчас в теме
(69) Все 3 базы клиент-серверные, на продакшене.

В общем я проверил. Заблокировал "Справочник.Пользователи", если открывать его в другой сессии или использовать консоль запросов, то данные из него прекрасно читаются. Но если запустить эту же обработку и попробовать установить Блокировку, то через 20 секунд выдает ошибку
"Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки"

Т.е. через управляемую блокировку можно обезопасить от чтения - идентичные объекты в разных сессиях с одним и тем же кодом, где идет попытка установки несовместимой блокировки. От запросов без использования объекта БлокировкаДанных - это не спасает.
71. PerlAmutor 129 03.05.19 19:59 Сейчас в теме
(70) Но вот что интересно. От ЗАПИСИ блокировка спасает. Установив исключительную блокировку в обработке на "Справочник.Пользователи" и попытавшись снять галочку "Показывать в списке" с последующей записью - я получаю все тот же конфликт блокировок.
Таким образом получается, что исключительная управляемая блокировка защищает от чтения только, если перед чтением идет попытка установки блокировки. Если нет, тогда она срабатывает уже при записи (видимо уже на уровне СУБД).
73. PerlAmutor 129 04.05.19 05:45 Сейчас в теме
(71) Правда, если блокировка будет снята после удачного чтения, но до попытки записи или в течении тех 20 секунд ожидания блокировки, то могут записаться некорректные данные. Таким образом в критичных местах надо обязательно использовать объект БлокировкаДанных явным образом, чтобы уберечь свой код от возможного чтения заблокированных данных.
76. comol 5051 06.05.19 00:04 Сейчас в теме
(70)
через управляемую блокировку можно обезопасить от чтения
можно конечно. Другой вопрос что это надо делать своими руками
75. comol 5051 06.05.19 00:03 Сейчас в теме
(68) Посмотрел. Ну ещё один пример аналогичный приведённому. Не ставим блокировки = не защищаемся. Собственно у вас они только в начале.
34. Dach 372 30.04.19 16:39 Сейчас в теме
И кстати, автор. По поводу блока кода №1. Замените набор регистра сведений набором регистра накопления - и Вы удивитесь)))

Спойлер:

Объектное чтение набора РС в транзакции накладывает неявную разделяемую управляемую блокировку.
Объектное чтение набора РН в транзакции НЕ накладывает неявную разделяемую управляемую блокировку.

Такое ощущение, что наборы записей РС и РН разные люди программировали в 1С.

Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.

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

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

И с вот этим Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении

не могу согласиться.

Зачем блокировать то, что я в результате выполнения алгоритма менять не собираюсь? Как раз таки это избыточно будет. Собираюсь менять остатки - вот их и блокирую. Ну а то, что товар на момент чтения был товаром, а потом стал услугой - ну извините, сами себе злые буратины. Это уже уровень защиты в прикладной логике должен отвечать, при записи вида/свойства номенклатуры. А то так можно эту цепочку продлить еще и еще, у вида/свойства номенклатуры тоже свои реквизиты есть, у тех тоже свои и т.д. и т.п. Что же нам - все разименования блокировать? Не надо так )))
alexsey777; CSiER; comol; +3 Ответить
35. comol 5051 30.04.19 16:56 Сейчас в теме
(34)
хотите обеспечить дополнительную "чистоту" и неизменность тех данных, которые читаете - ставьте перед чтением

В этом весь смысл данной статьи :)))) Дело в том что в типовых 1С их не ставит... при проведении документа "с контролем" очевидно должна быть "дополнительная чистота"
44. comol 5051 30.04.19 22:38 Сейчас в теме
(34)
Что же нам - все разименования блокировать
именно так а никак иначе. Представьте что у вас меняется не "товар на услугу" а "вагон нефти" на "вагон хлора" в распределенной системе :)

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

А вцелом коммент очень дельный
sergathome; +1 Ответить
64. CheBurator 3119 01.05.19 23:08 Сейчас в теме
65. acanta 02.05.19 00:31 Сейчас в теме
Спасибо. Пробелы постепенно заполняются.
72. acanta 03.05.19 20:58 Сейчас в теме
Вы хотите сказать, что если на всю таблицу справочника пользователи наложить исключительную блокировку, то при обновлении ранее открытого списка мы получим пустой список или неполный?
А как же политика оптимистических блокировок?
74. PerlAmutor 129 04.05.19 20:11 Сейчас в теме
(72) Оптимистические и пессимистические блокировки относятся к объектным блокировкам, в основном касаются интерактивного варианта работы. Управляемые (транзакционные) блокировки не будут накладывать эти варианты блокировок на записи при использовании (это два разных механизма, которые друг о друге ничего не знают). Как я понимаю, с версии 8.3 в режиме Управляемых блокировок СУБД MSSQL использует уровень изоляции RCSI (Read Commited Snapshot Isolation), что позволяет повысить параллельность работы (concurency) за счет того, что в момент блокировки записи на чтение - копия (версия) данных (текущей транзакции) помещается в TempDb, а остальные транзакции читают основную версию. В моем случае, установка блокировки справочника Пользователи на чтение приводит к тому, что все остальные транзакции по факту читают старую (существующую) версию справочника, до завершения моей транзакции. Если другие транзакции попробуют явно установить блокировку через БлокировкаДанных или неявно, когда сама СУБД начнет её устанавливать, через попытку записи справочника - тогда блокировка встанет в очередь.Если мы хотим избежать рассогласованности данных в собственной транзакции и считаем, что изменение данных другими транзакциями критично для нашей бизнес-логики, то необходимо установить блокировку в явном виде, чтобы механизм Управляемых блокировок 1С и СУБД среагировал. В противном случае считается, что считанная ("старая" версия) данных имеет право на существование, так как заранее неизвестно завершится транзакция удачей или нет. И все кто не наложил блокировку в явном виде - сам отвечает за последствия. Это не является ошибкой, так как решение принимается исходя из логики прикладного решения, и в основном играет положительную роль, увеличивая параллельность работы системы. Проблема может возникнуть, если мы ничего не блокируем, считываем "старую" версию и на основании этой информации пишем в совершенно другое место (в этом случаем блокировок надо накладывать, как минимум, две)

Поправьте меня если я не прав.
sergathome; +1 Ответить
77. comol 5051 06.05.19 00:09 Сейчас в теме
(74) Во всём прав (вроде как) кроме того что к форме списка справочника это никак не относится ибо там нетранзакционное чтение данных, которому абсолютно покласть на все блокировки и уровни изоляции :)
78. Quantum81 6 06.05.19 10:46 Сейчас в теме
Авто!!! Напугал!
Ты должен исключение получить, когда будешь блокировать второй раз регистр. Т.е. проводи эксперимент при всегда включенной галке блокировать. Вот если ты смог заблокировать данные, то и читай их, зная что никто их не поправит в этот момент, т.к. ты наложил блокировку.
81. comol 5051 06.05.19 11:23 Сейчас в теме
(78) Галка "блокировать" это неявная установка управляемой блокировки просто.
82. Quantum81 6 06.05.19 11:49 Сейчас в теме
(81) Вы, наверно, меня не поняли. У вас же документ проводится. Если установлена галочка блокировать, то вы накладываете ЯВНУЮ управляемую блокировку на регистр. Так вот чтобы не получать неконсистентных данных - это надо делать ВСЕГДА (блокировать). Если вы блокировку не наложили перед чтением - то оно будет ГРЯЗНОЕ. Что здесь удивительного? :)
unichkin; +1 Ответить
79. herfis 498 06.05.19 11:06 Сейчас в теме
Удивлен, что автор для многих открыл америку. Значит, статья в самом деле полезная.
ИМХО, если понимать, как работают блокировки СУБД и знать что управляемые блокировки не имеют никакого отношения к уровню СУБД, то вывод что управляемые блокировки никак не влияют на чтение запросами - очевиден.
Аналогичные реализации управляемых блокировок я еще на 7.7 припоминаю (с помощью внешних библиотек).
Астиг; sergathome; +2 Ответить
80. comol 5051 06.05.19 11:21 Сейчас в теме
(79)
вывод что управляемые блокировки никак не влияют на чтение запросами - очевиден

а можете пояснить почему для вас этот вывод очевиден?
Просто опыт говорит что в 1С работают одни разгильдяи и вот уж этого они точно не сделают? :)
83. herfis 498 06.05.19 11:59 Сейчас в теме
(80) Потому, что по тексту запроса невозможно в общем случае определить, пересечется ли получение результата запроса с управляемой блокировкой.
Ну вот смотрите. Наложил я блокировку по конкретному ТМЦ. А выбираю данные по всем ТМЦ из регистра за период. Анализом текста запроса невозможно определить - попадется ли там заблокированный ТМЦ. Анализом результата запроса это определить также невозможно - блокируемые данные могут использоваться как промежуточные и не входить в конечный результат. Приходим к тому, что контролировать это возможно только на уровне СУБД.
Но управляемые блокировки - это грубо говоря просто системный справочник. Полностью отдельно стоящая параллельная система. И ничего другого тут особо не придумаешь. Я бы реализовывал точно также. И как я уже говорил, подобные реализации были и для 7.7. Если не путаю, автор ToySQL что-то подобное продавал.
sergathome; +1 Ответить
89. comol 5051 06.05.19 13:11 Сейчас в теме
(83)
по тексту запроса невозможно в общем случае определить, пересечется ли получение результата запроса с управляемой блокировкой.
тем не менее СУБД это как то делает. Если очень хочется можно сначала прочитать а потом заблокировать. А можно тупо уровень изоляции поднять.
Я бы реализовывал точно также.
. Печально. Не смог донести видимо :(. Я бы такую херь делать не стал. И тому кто сделал по рукам бы надовал. Я бы дал возможность разработчику поднимать уровень изоляции. Или принудительно бы поднимал при проведении.
91. herfis 498 06.05.19 16:02 Сейчас в теме
(89) СУБД это делает с помощью блокировок СУБД. Уровень изоляции - это те же самые блокировки (плюс переключатель блокировочник/версионник в mssql).
С блокировками на уровне СУБД и поднятием уровня изоляций в 1С уже наигрались в автоматическом режиме блокировок. При проведении как раз и поднималось до Serializable. Но оказалось, что это не самый лучший вариант - слишком из пушки по воробьям. Целостность-то обеспечивается, но параллельность далеко не такая, как хотелось бы. Хотелось бы более тонкое управление блокировками, но его можно обеспечить только на прикладном уровне. Разбор полетов как раз и привел к появлению управляемых блокировок, которые можно применять "хирургически", а не "по площадям". Печально, что вы этого не понимаете. Здесь в принципе нет "более лучшей альтернативы".
ЗЫ. Хотя :) Если бы у 1С была своя СУБД, тогда 1С теоретически могла бы прямо транслировать управляемые блокировки в блокировки этой СУБД. Вот тогда бы могло получиться как вы хотите. Со сторонними СУБД на текущий момент это невозможно.
92. acanta 06.05.19 16:11 Сейчас в теме
(91) я понимаю в общих чертах что конфигурация на файловой СУБД и на sql с управляемыми блокировками долга быть не только написана с дополнительными командами заблокировать освободить, и даже не только с запросами (используя временные таблицы или нет) но и иметь другую архитектуру.
И несмотря на возможность открыть ее в конфигураторе, разработать конфигурацию для такого режима работы в файловой базе не получится и протестировать тоже.
94. spacecraft 06.05.19 16:23 Сейчас в теме
(92) да в общем-то нет. На то и универсальный объект Управляемые блокировки. Его стратегия определяет общие правила для разных СУБД. В том числе и для встроенного. Конечно есть особенности использования под разные СУБД, но они исключение из правила.
Это как запрос и СКД. В СКД тоже используется запрос, но он скорее руководство к действию, а не пошаговое выполнение.
Так и с управляемыми блокировками. Это объект (класс), который сам определяет, что и как заблокировать в самом sql.
95. comol 5051 06.05.19 16:26 Сейчас в теме
(92) (94) В общем то да. Я бы сказал "хорошая" конфигурация на 1С должна разрабатываться или под использование в файловой версии или под использование с конкретной СУБД.
Типовые конфигурации я не отношу к "хорошим" - я их отношу к "типовым".
93. comol 5051 06.05.19 16:22 Сейчас в теме
(91)
Уровень изоляции - это те же самые блокировки (плюс переключатель блокировочник/версионник в mssql)

"Садись два". Тут конечно нужно прочитать несколько матчасти. Уровень изоляции это намного более широкое понятие, и в общем случае не имеющее отношения к блокировочник/версионник.

Ещё раз постараюсь объяснить - надеюсь получится:

1) В СУБД реализованы НОРМАЛЬНЫЕ - ХОРОШИЕ блокировки. Которые вцелом всех устраивают.
2) Потому как в разных случаях разные требования к согласованности данных в СУБД придумали уровни изоляции. От Read Uncommited - когда нам "всё равно", до "Serializable" когда "не дай бог что сломается"
3) Блокировки в СУБД это целая нехилая система, с совместимостью, эскалацией, предварительным расчетом и т.п. которая ОЧЕНЬ сложна, но при этом отработана годами
4) УБ в 1С - это просто некие "флажки" - "тут можно, а тут нельзя", предельно упрощенная и не имеющая ничего общего с "тем как надо", более того - никак не распространяющаяся на реальные данные.


Так вот - 99% НОРМАЛЬНЫХ систем используют в своей работе механизм блокировок и транзакций от СУБД, потому как реализация аналогичного "очень трудна и дорога". И да, в них параллельность обеспечивается на лучшем уровне (Dynamix Ax и SAP (который не HANA)).

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

а про
более тонкое управление блокировками, но его можно обеспечить только на прикладном уровне
вы начитались методичек от 1С и просто не понимаете что это возможно БЕЗ 1С и БЕЗ управляемых блокировок.
96. spacecraft 06.05.19 16:27 Сейчас в теме
(93) а теперь отбросьте знания про последние версии mssql и оперируйте полным спектром поддерживаемых версий sql в 1С (в том числе и встроенной). А теперь создаете правило, которое поддерживается ими всеми и сразу.
97. acanta 06.05.19 16:32 Сейчас в теме
(96) что мешает 1с сузить поддерживаемые версии СУБД для каждого релиза конфигурации, как платформы к примеру.
Лицензионная политика ms sql?
98. spacecraft 06.05.19 16:34 Сейчас в теме
(97) предлагаете для каждой версии СУБД отдельную конфигурацию?
99. acanta 06.05.19 16:38 Сейчас в теме
(98) при запуске конфигурации пишут же обновите платформу. А почему не СУБД? Его надо заново покупать или только переустановить?
Оставьте свое сообщение