Здравствуйте, интересует вопрос, связанный с блокировками данных. Как я понимаю у нас есть несколько вариантов блокировки данных: объектные блокировки, управляемые блокировки и блокировки в запросе.
1. Объектные блокировки устанавливают блокировку объекта от интерактивных изменений и изменений в коде при условии, что изменяющий код также будет пытаться наложить на объект объектную блокировку.
2. Управляемые блокировки - блокировки строк или таблиц непосредственно БД от записи и чтения в транзакции
3. Блокировка в запросе - блокирует считываемые в транзакции указанные в запросе записи или таблицы БД (в зависимости от того файловый у тебя режим работы или клиент-серверный через одну из БД, с которой интегрирован 1С).
Возникает вопрос, какую из двух последних блокировок использовать при работе в транзакции, управляемую или блокировку в запросе через ключ. слово "Изменяемые"? И соответственно вопрос по отличию между этими блокировками. Как я понимаю управляемая блокировка накладывает ограничения до момента ручного, автоматического отключения или завершения транзакции. А на какой промежуток времени накладывается блокировка непосредственно в запросе? Также интересует тип блокировки при использовании ключ. слова "Изменяемые" - блокировка исключительная или разделяемые, и применимы ли вообще к такому типу блокировки данные термины? Ну и собственно главный вопрос, какая блокировка будет достаточной, могу ли я ограничиться управляемой и не париться по поводу "Изменяемые" в тексте запроса?
1. Объектные блокировки устанавливают блокировку объекта от интерактивных изменений и изменений в коде при условии, что изменяющий код также будет пытаться наложить на объект объектную блокировку.
2. Управляемые блокировки - блокировки строк или таблиц непосредственно БД от записи и чтения в транзакции
3. Блокировка в запросе - блокирует считываемые в транзакции указанные в запросе записи или таблицы БД (в зависимости от того файловый у тебя режим работы или клиент-серверный через одну из БД, с которой интегрирован 1С).
Возникает вопрос, какую из двух последних блокировок использовать при работе в транзакции, управляемую или блокировку в запросе через ключ. слово "Изменяемые"? И соответственно вопрос по отличию между этими блокировками. Как я понимаю управляемая блокировка накладывает ограничения до момента ручного, автоматического отключения или завершения транзакции. А на какой промежуток времени накладывается блокировка непосредственно в запросе? Также интересует тип блокировки при использовании ключ. слова "Изменяемые" - блокировка исключительная или разделяемые, и применимы ли вообще к такому типу блокировки данные термины? Ну и собственно главный вопрос, какая блокировка будет достаточной, могу ли я ограничиться управляемой и не париться по поводу "Изменяемые" в тексте запроса?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Неправильно понимаешь. Перечитай всё о блокировках. Большая часть твоих предположений неверна, поэтому поставленные тобой вопросы не имеют ответа, так как не имеют смысла
По порядку. У нас есть объектные блокировки двух видов, но ставить их в один ряд с другими не нужно. Больше различий чем сходства.
Есть транзакционные блокировки. Тоже двух видов. Управляемые(Сервера 1С) и автоматические(Сервера СУБД)
В пункте 1 ты описал пессиместические объектные блокировки. Есть еще оптимистические. Почитай.
В пункте 2 ты делаешь вольное допущение что управляемые блокировки как то относятся к субд и к данным. Это не так
Какие использовать? Те которые поддерживаются в конфигурации. Одновременно они не могут работать. Таблица либо в управляемом режиме блокировок и тогда через БлокировкаДанных либо в автоматическом и тогда Для Изменения. Оба варианта сразу невозможны
Все установленные блокировки длятся до конца транзакции, их нельзя отключить. Можно только усилить уровень изоляции. А без транзакции блокировки не существуют
Те что ставятся в запросе - не разделяемые и не исключительные, они средние между двумя этими типами - блокировки намерения.
На главный вопрос ответ выше. Если конфа в режиме управляемых, то слова "Для Изменения" в запросе игнорируются
По порядку. У нас есть объектные блокировки двух видов, но ставить их в один ряд с другими не нужно. Больше различий чем сходства.
Есть транзакционные блокировки. Тоже двух видов. Управляемые(Сервера 1С) и автоматические(Сервера СУБД)
В пункте 1 ты описал пессиместические объектные блокировки. Есть еще оптимистические. Почитай.
В пункте 2 ты делаешь вольное допущение что управляемые блокировки как то относятся к субд и к данным. Это не так
Какие использовать? Те которые поддерживаются в конфигурации. Одновременно они не могут работать. Таблица либо в управляемом режиме блокировок и тогда через БлокировкаДанных либо в автоматическом и тогда Для Изменения. Оба варианта сразу невозможны
Все установленные блокировки длятся до конца транзакции, их нельзя отключить. Можно только усилить уровень изоляции. А без транзакции блокировки не существуют
Те что ставятся в запросе - не разделяемые и не исключительные, они средние между двумя этими типами - блокировки намерения.
На главный вопрос ответ выше. Если конфа в режиме управляемых, то слова "Для Изменения" в запросе игнорируются
(4) Спасибо. Поправьте меня, если что-то не так или все не так, чтобы я мог в правильном направлении двигаться
1. Оптимистические и пессимистические блокировки - про них я знаю. Пессимистическая работает по принципу - выбросить исключение при попытке объектной пессимистической блокировки, если такая блокировка уже имеется. Оптимистическая - при интерактивной попытке записи данных проверяется версия считанного объекта и объекта в БД на данный момент, в случае различия запись не выполняется.
2. Управляемые блокировки. Если у нас есть транзакция, которой необходимо, чтобы какие-то данные оставались неизменными в процессе выполнения данной транзакции, тогда мы блокируем эти данные, используя механизм управляемых блокировок.
У меня возникают следующие вопросы, как я понял, когда мы в транзакции выполняем запрос к БД, на те таблицы, которые мы запрашиваем, накладывается неявная блокировка, снимающаяся неявно при окончании транзакции. Это верно? Из этого следует, что пока транзакция не закончится, другие транзакции не смогут прочесть/ изменить данные, неявно заблокированные этой транзакцией. Так? При этом при чтении вне транзакции, никакие блокировки на нас не действуют. При записи также выполняется неявная блокировка записываемых данных, так?
1. Оптимистические и пессимистические блокировки - про них я знаю. Пессимистическая работает по принципу - выбросить исключение при попытке объектной пессимистической блокировки, если такая блокировка уже имеется. Оптимистическая - при интерактивной попытке записи данных проверяется версия считанного объекта и объекта в БД на данный момент, в случае различия запись не выполняется.
2. Управляемые блокировки. Если у нас есть транзакция, которой необходимо, чтобы какие-то данные оставались неизменными в процессе выполнения данной транзакции, тогда мы блокируем эти данные, используя механизм управляемых блокировок.
У меня возникают следующие вопросы, как я понял, когда мы в транзакции выполняем запрос к БД, на те таблицы, которые мы запрашиваем, накладывается неявная блокировка, снимающаяся неявно при окончании транзакции. Это верно? Из этого следует, что пока транзакция не закончится, другие транзакции не смогут прочесть/ изменить данные, неявно заблокированные этой транзакцией. Так? При этом при чтении вне транзакции, никакие блокировки на нас не действуют. При записи также выполняется неявная блокировка записываемых данных, так?
(8)Пункт 2.
Управляемые блокировки никак не связаны с данными. Мы не блокируем данные. Мы делаем запись в таблицу блокировок. Причем запись будет на сервере 1С. Например исключительную. И дальше, когда платформа или наш явный код захочет добавить такую-же запись в таблицу блокировок - он будет ждать. Данных вообще может не быть. Например у вас есть склад Основной и Дополнительный. На основном складе остатки есть, Дополнительный вообще никогда не использовался. Вы пишете код и блокируете Слона на Дополнительном. На остатках у вас ноль слонов, даже на основном складе, а Дополнительный вообще пуст.
Вы запускаете две транзакции со своим кодом и одна из них будет ждать другую. Потому что блокировки есть, хотя данных нет.
Управляемые блокировки никак не связаны с данными. Мы не блокируем данные. Мы делаем запись в таблицу блокировок. Причем запись будет на сервере 1С. Например исключительную. И дальше, когда платформа или наш явный код захочет добавить такую-же запись в таблицу блокировок - он будет ждать. Данных вообще может не быть. Например у вас есть склад Основной и Дополнительный. На основном складе остатки есть, Дополнительный вообще никогда не использовался. Вы пишете код и блокируете Слона на Дополнительном. На остатках у вас ноль слонов, даже на основном складе, а Дополнительный вообще пуст.
Вы запускаете две транзакции со своим кодом и одна из них будет ждать другую. Потому что блокировки есть, хотя данных нет.
(15)Смотрите, еще раз перечитал всю инфу, что нашел по упр. блокировкам на итс.
Получается следующее, мы используем управляемые блокировки в транзакциях, для того, чтобы блокировать какие-то области данных от захвата другими транзакциями. Все это происходит на уровне платформы. То есть у нас есть менеджер транзакционных блокировок, в транзакции с помощью объекта БлокировкаДанных мы добавляем в менеджер определенные области данных и, если параллельные другие транзакции пытаются также добавить в менеджер уже имеющиеся в нем области данных, то они не могут этого сделать до тех пор, пока транзакция, успевшая ранее заблокировать эти данные, не освободит их, зафиксировав транзакцию или откатив ее (здесь я умышленно опустил виды блокировок: разделяемые и исключительные, чтобы упомянуть их позднее). К непосредственно СУБД блокировки отношения не имеют, это абстракция на уровне платформы, также как и области данных - абстракция, которая не является тем же самым, что и реальные таблицы СУБД. Как написано на ИТС, лучше всего воспринимать добавляемые в менеджер транзакционных блокировок области данных как некую сущность, которая блокирует записи таблицы СУБД, удовлетворяющие условиям, указанным при создании элементов объекта БлокировкаДанных.
Блокировки бывают двух видов: исключительные и разделяемые. В одно время несколько транзакций могут накладывать, не конфликтуя друг с другом, только разделяемые блокировки. Исключительные блокировки не сочетаются ни с какой другой.
Это то, что я понял. Теперь, что до сих пор не могу понять.
1. У меня файловая база, необходимо ли в рамках файловой базы задумываться об управляемых блокировках?
2. Стоит ли, разрабатывая алгоритм в контексте файловой базы, разрабатывать его с оглядкой на нефайловые базы данных (переход на нефайловую бд в обозримом будущем не предвидится), учитывать, что в нефайловых базах используется уровень блокировки read commited, а в файловой serialized?
3. Неявные блокировки, знаю, что устанавливаются при записи и при чтении в транзакции. Не могу понять, на что устанавливаются блокировки при чтении в транзакции, до какого момента действуют, до конца чтения или до конца транзакции, если чтение происходит в рамках транзакции.
4. Когда использовать разделяемые блокировки, а когда исключительные?
Получается следующее, мы используем управляемые блокировки в транзакциях, для того, чтобы блокировать какие-то области данных от захвата другими транзакциями. Все это происходит на уровне платформы. То есть у нас есть менеджер транзакционных блокировок, в транзакции с помощью объекта БлокировкаДанных мы добавляем в менеджер определенные области данных и, если параллельные другие транзакции пытаются также добавить в менеджер уже имеющиеся в нем области данных, то они не могут этого сделать до тех пор, пока транзакция, успевшая ранее заблокировать эти данные, не освободит их, зафиксировав транзакцию или откатив ее (здесь я умышленно опустил виды блокировок: разделяемые и исключительные, чтобы упомянуть их позднее). К непосредственно СУБД блокировки отношения не имеют, это абстракция на уровне платформы, также как и области данных - абстракция, которая не является тем же самым, что и реальные таблицы СУБД. Как написано на ИТС, лучше всего воспринимать добавляемые в менеджер транзакционных блокировок области данных как некую сущность, которая блокирует записи таблицы СУБД, удовлетворяющие условиям, указанным при создании элементов объекта БлокировкаДанных.
Блокировки бывают двух видов: исключительные и разделяемые. В одно время несколько транзакций могут накладывать, не конфликтуя друг с другом, только разделяемые блокировки. Исключительные блокировки не сочетаются ни с какой другой.
Это то, что я понял. Теперь, что до сих пор не могу понять.
1. У меня файловая база, необходимо ли в рамках файловой базы задумываться об управляемых блокировках?
2. Стоит ли, разрабатывая алгоритм в контексте файловой базы, разрабатывать его с оглядкой на нефайловые базы данных (переход на нефайловую бд в обозримом будущем не предвидится), учитывать, что в нефайловых базах используется уровень блокировки read commited, а в файловой serialized?
3. Неявные блокировки, знаю, что устанавливаются при записи и при чтении в транзакции. Не могу понять, на что устанавливаются блокировки при чтении в транзакции, до какого момента действуют, до конца чтения или до конца транзакции, если чтение происходит в рамках транзакции.
4. Когда использовать разделяемые блокировки, а когда исключительные?
(19)
1. Файловая база никогда всерьез не рассматривается в контексте параллельной работы. Опыта по ней нет и врядли кому этот опыт интересен. К тому моменту как программисту становятся нужны блокировки, у него в базе уже 100+ человек и она явно не файловая.
2. Сделать не файловую бд это 80 тыс денег. СУБД можно постгресс взять бесплатно. В рамках бюджета IT отделов это копейки. Для мелких контор есть сервер 1С за 14тыс на 5 человек.
3. Про неявные блокировки тоже есть информация в инете. Длятся они как и всегда до конца транзакции, либо до замены на более сильную блокировку.
4. Все случаи что мне встречались когда явно требовалась управляемая блокировка, она была исключительной. Можно попробовать придумать ситуацию когда нужна будет именно явная разделяемая. На очном экзамене 1С эксперт я не смог такое придумать.
1. Файловая база никогда всерьез не рассматривается в контексте параллельной работы. Опыта по ней нет и врядли кому этот опыт интересен. К тому моменту как программисту становятся нужны блокировки, у него в базе уже 100+ человек и она явно не файловая.
2. Сделать не файловую бд это 80 тыс денег. СУБД можно постгресс взять бесплатно. В рамках бюджета IT отделов это копейки. Для мелких контор есть сервер 1С за 14тыс на 5 человек.
3. Про неявные блокировки тоже есть информация в инете. Длятся они как и всегда до конца транзакции, либо до замены на более сильную блокировку.
4. Все случаи что мне встречались когда явно требовалась управляемая блокировка, она была исключительной. Можно попробовать придумать ситуацию когда нужна будет именно явная разделяемая. На очном экзамене 1С эксперт я не смог такое придумать.
(9)
это может делать только админ СУБД при условии,
что клиент начал транзакцию и забыл ( на полчаса ) завершить ее :)
а начальнику нужно сейчас смотреть данные,которые недоступны .
тогда умный админ выгоняет спящего клиента ( запрет доступа или разрыв сеанса ),
а начальник получает доступ
снять явно установленную нами блокировку в транзакции
это может делать только админ СУБД при условии,
что клиент начал транзакцию и забыл ( на полчаса ) завершить ее :)
а начальнику нужно сейчас смотреть данные,которые недоступны .
тогда умный админ выгоняет спящего клиента ( запрет доступа или разрыв сеанса ),
а начальник получает доступ
(9)
1) Нет, не можем. Никак. Вообще никак.
Можно только саму транзакцию прервать, она откатиться и блокировки снимутся
2)Зависит от того какой режим управления блокировками в конфигурации. От того выполняется запрос в транзакции или вне её. От используемой СУБД и настроек этой СУБД. От того читаем ли мы данные до записи или после. От того сработала эскалация или нет. При автоматическом управлении блокировками и запросе в транзакции влияет также ключевое слово "Для Изменения" в запросе.
1) Нет, не можем. Никак. Вообще никак.
Можно только саму транзакцию прервать, она откатиться и блокировки снимутся
2)Зависит от того какой режим управления блокировками в конфигурации. От того выполняется запрос в транзакции или вне её. От используемой СУБД и настроек этой СУБД. От того читаем ли мы данные до записи или после. От того сработала эскалация или нет. При автоматическом управлении блокировками и запросе в транзакции влияет также ключевое слово "Для Изменения" в запросе.
(2)
Не совсем так.
В запросе в автоматическом режиме управления блокировок, можно поставить U-блокировку (изменения/обновления). Блокировки намерения же, это IS, IX, IU - это отдельный вид блокировок, которые устанавливаются на другом уровне гранулярности и используются для оптимизации получения информации о наличии блокировки.
Например, у нас стоит Х-блокировка на конкретной строке таблицы. При этом ставится блокировка IX на всю таблицу. Соответственно если другая транзакция захочет установить Х-блокировку на таблицу, ей не нужно будет проверять наличие Х-блокировок для каждой строки, а будет достаточно проверить наличие IX-блокировки на таблице.
Те что ставятся в запросе - не разделяемые и не исключительные, они средние между двумя этими типами - блокировки намерения.
Не совсем так.
В запросе в автоматическом режиме управления блокировок, можно поставить U-блокировку (изменения/обновления). Блокировки намерения же, это IS, IX, IU - это отдельный вид блокировок, которые устанавливаются на другом уровне гранулярности и используются для оптимизации получения информации о наличии блокировки.
Например, у нас стоит Х-блокировка на конкретной строке таблицы. При этом ставится блокировка IX на всю таблицу. Соответственно если другая транзакция захочет установить Х-блокировку на таблицу, ей не нужно будет проверять наличие Х-блокировок для каждой строки, а будет достаточно проверить наличие IX-блокировки на таблице.
(6)
Атомарность. Транзакция либо выполняется полностью либо не выполняется вовсе.
Согласованность. При завершении транзакции не должны быть нарушены ограничения накладываемые на данные (например constraints в БД). Согласованность подразумевает, что система будет переведена из одного корректного состояния в другое корректное.
Изолированность. Параллельно выполняемые транзакции не должны влиять друг на друга, например менять данные которые использует другая транзакция. Результат выполнения параллельных транзакций должен быть таким, как если бы транзакции выполнялись последовательно.
Устойчивость. После фиксации изменения не должны быть утеряны.
к данным не всегда такие требования
Атомарность. Транзакция либо выполняется полностью либо не выполняется вовсе.
Согласованность. При завершении транзакции не должны быть нарушены ограничения накладываемые на данные (например constraints в БД). Согласованность подразумевает, что система будет переведена из одного корректного состояния в другое корректное.
Изолированность. Параллельно выполняемые транзакции не должны влиять друг на друга, например менять данные которые использует другая транзакция. Результат выполнения параллельных транзакций должен быть таким, как если бы транзакции выполнялись последовательно.
Устойчивость. После фиксации изменения не должны быть утеряны.
к данным не всегда такие требования
последовательность операций над данными
запрос и изменение не одно и тоже
если вы или 25 клиентов смотрят таблицу или строку - проблем нет
но если я меняю эту строку - то другие уже ждут
или видят старую версию,
но изменять одновременно два разных клиента одну строчку не могут (!)
запрос и изменение не одно и тоже
если вы или 25 клиентов смотрят таблицу или строку - проблем нет
но если я меняю эту строку - то другие уже ждут
или видят старую версию,
но изменять одновременно два разных клиента одну строчку не могут (!)
(10) я это понял, просто немного запутался с управляемыми блокировками. Ситуация такая. Выполняется групповое изменение товаров (объект справочник), каждый объект связан с категорией (объект справочник), у каждой категории есть шаблон наименования (объект справочник). Все групповое изменение выполняется в рамках единой транзакции. Мне необходимо, чтобы пока эта операция выполняется, не вносились изменения в товары, не вносились изменения в категории и не вносились изменения в шаблоны. Потому что, групповое изменение завязано на принадлежности товаров к категории и на шаблонах наименований, привязанных к категориям. Я правильно понимаю, что мне нужно на время транзакции установить блокировку таблиц/записей, которые я задействую для чтения/изменения в рамках этой групповой обработки? У меня файловая база, так что на записи наложить блокировку я не могу, мне, как я понял, нужно блокировать 3 таблицы: товары, категории, шаблоны наименований, так получается?
(11)
не думаю, что групповые изменения нужно делать в рабочее время :)
да еще при поступлении товара, например
__________
вы откройте номенклатуру для изменения
и попробуйте с другого клиента в это время сделать тоже :)
а если вы заблокируете всем доступ к справочникам , то это не очень хорошо
обычно в это время кто-то да срочно захочет менять
так что лучше делать групповое изменение вне рабочее время
( или обед перенесите , а во время обеда других - делайте )
и это все при условии, что вы понимаете последствия :)
попробуйте на 100 наименований и подождите день, чтобы потом не было печально.
не думаю, что групповые изменения нужно делать в рабочее время :)
да еще при поступлении товара, например
__________
вы откройте номенклатуру для изменения
и попробуйте с другого клиента в это время сделать тоже :)
а если вы заблокируете всем доступ к справочникам , то это не очень хорошо
обычно в это время кто-то да срочно захочет менять
так что лучше делать групповое изменение вне рабочее время
( или обед перенесите , а во время обеда других - делайте )
и это все при условии, что вы понимаете последствия :)
попробуйте на 100 наименований и подождите день, чтобы потом не было печально.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот