блокировки при записи в регистр сведений #659368

При добавлении данных в регистр сведений какие блокировки накладываются на таблицу регистра? Есть ли зависимость типа блокировок от способа добавления записи(набор или менеджер записей)? Могу ли я увеличить параллельность добавления записей в регистр сведений?

вот почитай, очень интересно)

мда) увлекательно!) ответов не дало но порадовало!)

Если у тебя автоматические блокировки то значит у тебя уровень изоляции Repeatable read. Если ты делаешь запись в транзакции то соответственно любые чтения у тебя блокируют и запрешают изменения. Если у тебя управляемые блокировки то уровень изоляции понижается до уровень изоляции понижается до read committed и нужно вручную накладывать блокировки. Смысл их один Писатель, много читателей. Перед записью накладывай исключительную блокировку, а  если хочешь, что бы данные не менялись в процессе транзакции накладывай Разделяемый

Смысл все делать в транзакции

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

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

Идею блокировок я понимаю. Пытаюсь понять как их отрабатывает платформа по умолчанию. Режим блокировок у РС управляемый, но в коде блокировки не прописаны. В этот РС параллельно пишутся данные. Пытаюсь понять, можно ли и нужно ли что-то сделать, чтобы параллельные добавления данные не мешали друг другу. судя по всему на регистр накладываются разделяемые блокировки с отбором по записываемым измерениям, и по скольку наборы измерений различны процессы благополучно выполняются параллельно. Нет необходимости прописывать управляемую блокировку с отбором по измерениям?

пиши в несколько сеансов по разным комбинациям основных отборов

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

при модификации данных, в управляемом режиме блокировки накладываются автоматически менеджером блокировок 1С.

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

+ одни и те же - по виду метаданных, ключевые измерения, естественно, раные

Спасибо! Всем спасибо!

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

"обычно" это как?

не обычно а

Обычно когда нужно сначала рассчитать считывая данные с разных регистров, а затем записать. Есть варианты когда можно записывать сразу без дополнительных расчетов. Что касается 9 то это не совсем верно. Исключительная блокировка предотвращает не только чтение но и запись предотвращая дид луки. Если две транзакции сначала сделают разделяемую блокировку а затем начать писать, то ничего не выйдет, будут блокировать друг друга . Поэтому исключительная блокировка сначала ждет завершения всех транзакций, а затем уже делает с этими данными что хочет. Это аналог блокировок много читателей один писатель. Зная что ты будешь эти данные модифицировать и проводя предварительно расчеты.

Есть еще хинты позволяющие увеличить скорость параллельной работы updlock

. Блокировки типа Update нужны для обозначения такого факта: те, кто уже имеет Shared locks на этот же ресурс могут продолжать ими пользоваться, но любые новые блокировки запрещены. Как только shared locks уходят с ресурса блокировка типа U конвертируется в eXclusive, чтобы обозначить соответственно названию, что никакими другими сессиями этот ресурс не заблокирован вообще. Короче, смысл блокировок U - не блокировать данные _читаемые_ при выборке под UPDATE, а обозначать факт того, что мы намереваемся менять данные сразу после того как уйдут те, кто их сейчас читает. То есть ты можешь не дожидаться окончания  shared locks  как это было бы с eXclusive но до записи совместно читать данные.

Поскольку взаимоблокировка произошла из-за того, что транзакции удерживали коллективные блокировки и потом попытались их повысить до эксклюзивных, то, в принципе, помочь избежать неприятностей в данном случае сможет понижение уровня изоляции до READ COMMITED. При этом коллективная блокировка не будет держаться до конца транзакции, а снимется сразу после завершения чтения, а значит, обновить записи ничто не помешает. Но тогда вместо взаимоблокировки мы вполне можем получить неверные данные, так как между SELECT и UPDATE сможет втиснуться другая транзакция, которая изменит Y и данные, полученные SELECT’ на момент UPDATE, окажутся неактуальными, чего в некоторых случаях допускать нельзя. Можно также сразу при чтении наложить эксклюзивную блокировку, но это тоже не самый лучший выход с точки зрения производительности, так как могут существовать транзакции, которым эти данные надо просто прочитать, а наложение эксклюзивной блокировки увеличивает время их пассивного ожидания. В общем случае наилучшим выходом здесь будет наложение при чтении промежуточной блокировки обновления. Такая блокировка совместима с коллективной, что позволит читающим транзакциям обращаться к этим данным беспрепятственно. А когда понадобится их обновить, то проблем быть не должно, так как блокировки обновления между собой несовместимы, и значит, другие транзакции, читающие эти данные для последующего изменения (и естественно тоже запросившие их с блокировкой обновления), будут ждать, пока эти данные поменяются, никому не мешая. Для этого необходимо изменить первый оператор транзакции примерно таким образом: SELECT @Var = Y FROM Tbl WITH (UPDLOCK) WHERE X = 2