Добрый день, а может утро, коллеги по цеху.

Подскажите пожалуйста, как устанавливается оптимистическая блокировка?

Везде пишут, что пессимистическая блокировка устанавливается методом объекта .Заблокировать() или методом глобального контекста ЗаблокироватьДанныеДляРедактирования.
А про оптимистическую блокировку пишут, что если запись была изменена, то при сохранении объекта будет ошибка.
Но как устанавливается оптимистическая блокировка, какой код, почему-то не пишут.

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

> Но как устанавливается оптимистическая блокировка, какой код, почему-то не пишут.
А она всегда работает и так.

Жди 8.3.15 (можно скачать ознакомительную версию) - там это есть.
Или попробуй это http://catalog.mista.ru/public/1043344/

(2) + "оптимистическая блокировка гарантирует, что пользователь изменяет актуальные данные объекта, которые хранятся в информационной базе, а не какой-то их предыдущий вариант"

(4) Это то понятно
(2) А о том, что это и так работает, нигде не написано

(5) Так никто твои фантазии (что она где-то как-то или когда-то "устанавливается") развенчивать не обязан

(3) Да это всё понятно. Вопрос в том, что везде написано, что для пессимистической блокировки надо в коде вызвать метод "Заблокировать", а для оптимистической ничего не написано.

+(6) Ты сам себе что-то там придумал и теперь ищешь этому подтверждение

(6) Здрасте, написано - блокировка! Оптимистическая. Если блокировка, значит она должна устанавливаться. А если она не устанавливается, то какая она к лопухам блокировка. Это просто при записи проверка версии.

(8) Всё должно быть чётко. Заблокировать() - пессимистическая блокировка. А как для оптимистической - непонятно...

Хочу понять, как установить на объект оптимистическую блокировку.

(9) "Если блокировка, значит она должна устанавливаться" // Как видишь, твой вывод не соответствует действительности.
"если она не устанавливается, то какая она к лопухам блокировка" // Это уже к ребяткам из 1С вопрос. Ты еще про свойство "БлокироватьДляИзменения" спросил бы, бгг.

В какой момент устанавливается эта блокировка? Или просто при редактировании меняется номер версии? Тогда где блокировка?

"Тогда где блокировка?" // В отлупе-сообщении пользователю. Ему не дают записать, "блокируют" это действие.

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

(15) Это ложь, зачем ее кому-то где-то писать?

(16) А что же тогда правда?

(16) оптимистической блокировки не бывает?

(17) Ты пытаешься распространить свойство "длящаяся во времени" других блокировок (блокировка - значит, она имеет начало и конец) на оптимистичную блокировку - в этом твоя ошибка

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

В СУБД есть множество блокировок, которые не устанавливаются явно. Тем не менее они работают и называются блокировками.

(20) То есть в момент записи, без каких-либо дополнительных операторов, устанавливается блокировка. Это оптимистическая блокировка. И она смотрит, если нет других оптимистических блокировок, то записывает объект в БД.

(22) Нет, она смотрит, не прошла ли запись другой оптимистической блокировкой

А если объект заблокирован пессимистической блокировкой. То запишется ли этот же объект оптимистической?

(24) По идее да. Запишется. Но при записи пессимистически заблокированного объекта, всё равно будет сработана защита блокировки оптимистической. То есть даже если мы пользуемся пессимистической блокировкой, оптимистическая также будет в момент записи.

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

(22) (23) Не выдумывай отсебятину. Смотрит только, что данные были изменены другим сеансом. Неважно каким способом.

(24) Запишется. А тот сеанс, гда была пессимистическая, при записи получит ошибку.

(26) Вообще говоря, термин "оптимистическая блокировка" не совсем корректный. В английском нет термина "optimistic lock", а есть только "optimistic locking". Что точнее перевести, как "оптимистическое блокирование [данных]".

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

Таким образом, оптимистическое блокирование — это такая хитрая техника контроля целостности данных без явных блокировок.

(28) хитрая техника на нехитром поле версия

(26) Что неясно-то? При изменении версии объекта его запись БЛОКИРУЕТСЯ системой. Всегда. Надеюсь, понятно зачем?
Почему оптимистическая? Потому что проверка производится при записи - т.е. в самый последний момент. В оптимистическом предположении, что версия изменена не будет.
Если у вас когнитивный диссонанс с понятием "блокировка" как с действием и как с отдельной сущностью - ну, раскройте мозг, осознайте многообразие языка и смиритесь с этим.

блокировка наступает, даже когда обэтом программист и не позаботится для сохранения целостности данных. Например, ты записал набор регистра накопления. В этот момент система создает блокировку до момента обеления записанных данных, т.е. до момента окончания транзакции (или транзакций), в которой происходит эта запись. А если ты после записи регистра накопления проверил остатки, и они тут стали  отрицательными, то установив Отказ=Истина в модуле проведения ты откатываешь уже сделанную запись регистра накопления,и если никто не читает (нет прав) грязные данные в базе, то твоей записи набора данных для других сеансов как-бы не происходит, хотя физически данные записываются и затем удаляются внутри транзакции. А если кто-то из другого сеанса пытается изменить тот же набор данных, пока еще действует твоя транзакция, то он будет послан блокировкой ожидать окончания транзакции.

(30) Блокируется только для тех, кто начал уже изменение.

(32) Хотя на самом деле ничего не блокируется, только изменяется версия.

(33) Блокируется выполнение записи объекта. Не "накладывается блокировка" на запись. А просто блокируется выполнение записи. Да, это просто банальная проверка на версию. Да, это проверка безусловная.
Вот тебе РТФМ:
"Оптимистическая блокировка запрещает запись объекта в базу данных, если после считывания объекта он был изменен в базе данных другими сеансами или другими программными объектами этого же сеанса. Фактически, оптимистическая блокировка представляет собой проверку, которая выполняется перед записью объекта в базу данных. Эта проверка построена на анализе номера версии объекта, хранящейся в базе данных и номера версии, помещенной в память компьютера в момент считывания данных из информационной базы. Если при записи объекта номера его версий отличаются, то будет выдано предупреждение о том, что версия объекта изменилась или он был удален, то есть сработает оптимистическая блокировка"

Еще бы при записи без изменений научиться не менять номер версии.

(35) Легко. Всего-то при записи без изменений не делать запись.

(36) Ага, особенно с кучей полей типа ХЗ.

Лучше научиться не использовать служебное поле номер версии не по назначению.

Лучше бы в номер версии добавили сахара, чтоб ее можно было по хронологии упорядочивать. Эдакое поле timestamp.

(25) Во бред. Неужели до вас никто никогда не доносил смысл понятий оптимистической и пессимистической блокировки?

(38) Не выйдет.

(38) Кого упорядочивать? В конкретной записи существует единственное значение номер версии. Упорядочивать некого. Если конечно при каждой записи не копировать предыдущее состояние в отдельное хранилище (например РС "версии объектов"). Вот там (в отдельном хранилище) можно и поупорядочивать. В исходной таблице должна существовать единственная запись с единственным значением "версия". Пусть даже и таймштамп. Просто для того, чтоб система могла определить изменились ли данные с момента последнего чтения. Все. Больше ни для чего.

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

(42) Гарантировать упорядоченность этого timestamp по времени будет очень сложно (несколько серверов в кластере и т.п.). А без гарантий он не нужен.

(43) Ну в случае с другими источниками данных (сторонние СУБД) этот вопрос же как-то решается. Там тоже может быть несколько серверов БД в кластере.

(42) Что вам даст время изменения записи? Важно знать что после _последнего_ _вашего_ чтения они изменились. И какая разница сколько раз? А тем более в каком порядке? Перечитать промежуточное состояние не получится. Да оно и не нужно в реляционных данных.

(44) Где именно он решается? Ты про 1С или что?

(45) Ну так в твоем случае чтобы понять что запись изменилась нужно пробежаться по _всей_ таблице и сравнивать. А в случае со штампом времени на запрос выборки накладывается фильтр и если это поле индексируемое, то получается профит.

(46) "в случае с другими источниками данных (сторонние СУБД)" решается. Не про 1С конечно же - про СУБД.

(47) "нужно пробежаться по _всей_ таблице". Абсолютно не нужно. Нужно сравнить номер версии "у меня на руках" и в таблице. И если они разные - я буду знать что запись изменилась.

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

(50) Это зависит от архитектуры. Я например не представляю (или плохо представляю) насколько нужно денормализовать таблицу, что б данные об одном объекте были в нескольких записях. Обычно это все-таки одна запись.

(48) На уровне СУБД решается тоже сложно. Например, специальный сервис следит за точной синхронизацией времени на узлах. Желательно по отдельному каналу связи.

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

(51) Так никто про "об одном объекте" и не говорит - задача получать все объекты, измененные с последней итерации засасывания

(52) Вообще так-то понятно, почему ребятки из 1С не хранят там какое-то точное время: потому что какую бы маленькую гранулу не делать, всегда может быть так что объект будет за этот минимальный интервал изменен не один раз. Я в общем-то про хранение точного штампа и не просил в (38), а лишь про гарантированный порядок (чтобы опять-таки выборка быстрой была за счет работы индекса)

(54) Какой еще нафиг индекс? :))

(55) По упорядочиваемому полю, см. (47)

(55) Чтобы быстро искать поле в строке ))).
Не ну а че? Запись в таблице по индексу можно. А поле в записи нет? )))

(57) Пример задачи описан в (42) и повторен тебе в (50). Но ты почему-то пытаешься "съехать" с темы, так что пока складывается впечатление, что ты либо бакланишь, либо троллишь.

(56) Блин, начинается...
Еще один индекс гарантированно ухудшает время отклика (его, в отличие от других индексов, нужно обновлять всегда). А insert в таблицу изменений дешевле. Все придумано до нас, и не просто так.

(58) А-а-а... Вы здесь о своем? А я думал - о блокировках, чистом и грязном чтении, отметках версий... А оно вон оно как...

(59) Довод конечно же принимается, но вот по ссылкой же (УИДом), получаемой через менеджер объекта метаданных (а не просто через конструктор), сделали по факту то же самое - он уникален и упорядочен. Твой посыл из (37) сразу был ясен )

(60) Я уже хз кто тут о чем )

(61) Упорядоченность во времени не гарантируется. И по-моему, не используется (платформой).

(63) Все так. Мой посыл просто исходил из того, что раз это уже сделали, то могли бы сделать еще разок для другого поля. Впрочем, твои аргументы оказались действенными - профит от этого не стоит выделки, да и скрещивание ужа с ежом почти никогда до добра не доводят. Оставим полю "Версия данных" его прямое назначение - быть уникальным в рамках одного ссылочного объекта, и не более того :)

(64) Скорее всего уид платформа берет просто системной функцией. А [псевдо]упорядоченность там появляется как побочный эффект от обеспечения уникальности.