Нужно создать один электронный код для справочников и документов. Проблема в блокировках. Я храню это код в регистре сведений и в самом объекте. Перед записью объекта запрашивается максимальный номер, к нему добавляется 1 и он присваивается реквизиту объекта. В событии при записи электронный код сохраняется в рс(берется из значения реквизита). Для контроля уникальности рс надо полностью заблокировать, чтоб никто не смог считать неверный код. Блокировка происходит в самом начале транзакции записи, что в случае с документами вообще нехорошо, так как проведение документа может происходить не быстро. Можно что то другое придумать?

(0) > Нужно создать один электронный код для справочников и документов
А ограничен ли ты в формате этого кода?
Обязательно ли это должны быть последовательные цифры, или может быть подойдет уникальная строка длиной символов 100?

Только число.

"Блокировка происходит в самом начале транзакции записи,"
- речь идет о блокировке РС? и это почему это РС блокируется в самом начале транзакции записи?

(3) По определению...

(17) Отложенная запись в регистр сведений, например через запущенный регламент после записи документа.

Добавь справочник ЭлектронныеКоды с реквизитом НумеруемыйОбъект (ЛюбаяСсылка)

(6) А что, на справочник транзакция не распространяется?
(5) и пропустить номера...

(7) Как они пропустятся, блокировать регистр при записи нового номера. Только блокировка будет недолгой - не на время записи/проведения документа.

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

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

Ну, или откажись от идеи единого нумератора.

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

Создать справочник "ЭлектронныеКоды". У нужных объектов добавить реквизит "ЭлектронныйКодСпр" с типом ссылка на этот справочник. В подписке на событие "обработка заполнения" создавать элемент справочника "ЭлектронныеКоды" и устанавливать значение реквизита в создаваемом объекте. При этом за сам электронный код (число) будет отвечать код справочника "ЭлектронныеКоды". Этот код можно и присвоить объекту как электронный код(число). В самом справочнике "ЭлектронныеКоды" ссылку на объект хранить не нужно.

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

(10) да хрена лысого! Не видишь потому, что просто смотреть не хочешь. Поверх твоего решения еще нужно городить костыли, которые помешают двум одновременно записываемым объектам подхватить один и тот же код. А это можно сделать только блокировкой.

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

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

Да даже "перед записью" можно. Платформа сама будет контролировать уникальность кода справочника "электронные коды"

Не сообразил сразу

(15) возьми "профессиональную разработку", там подробно расписано, почему нихрена не изменится. В разделе, где нарисовано, когда начинаются и заканчиваются транзакции.

В обработчике события "ПередЗаписью" объекта с электронным кодом будет создаваться и записываться элемент справочника "ЭлектронныеКоды". Его код будет присваиваться реквизиту объекта "ЭлектронныйКод". Уникальность кодов обеспечивает платформа.

(4) А откуда система знает, что в транзакции, которая началась будет использоваться РС1, а не РС5..?

(19) В какой ты записал, тот и будет блокироваться. В самом общем случае, в файловой - весь. В продвинутом, с управлемыми блокировками - тот кусок, что заблокировал

+20 - мне удивительно, что _тебе_ приходится рассказывать такие вещи....

(21) Злопчинский - старовер-клюшколожецъ, ему простительно

(22) В клюшках не было транзакций и табличных блокировок?

(23) там не было регистров сведений

(20) ты мне пургу не гони ;-)
(возможноя не знаю особенностей построения 8-ки).
Документ. Транзакция записи для документа. Транзакция где-то начинается и где-то заканчивается. Внутри этих "транзакционных скобок" может быть обработано кучу разных объектов - документов, справочников, регистров итд.
в какой именно момент внутри этих транзакционных скобок блокируется РС?
я вот почему-то думаю что система нихрена не знает какой именно РС будет использоваться в каком-то месте алгоритма в этих транзакционных скобках. и система нихрена не ставит блокировку на РС при начале "транзакционных скобок".

(25) Если ты в транзакции читаешь РС - никто тебе слова не скажет.
А как только ты туда запишешь... Всё, Митькой звали...

(26) вопрос не про это. в какой конкретно момент блокируется РС в транзакции записи документа (считаем что внутри транзакции записи документа используется запись в РС).

(27) В тот момент, когда ты первый раз туда что-то запишешь. Вроде уже третий раз пишу....

(28) ну так я про это и говорю: в тот момент, когда ты первый раз туда что-то запишешь. НО никак не в начале транзакции записи документа.

(29) А кто говорил про _начало_ транзакции?

(30)  намекают про то, чтобы перенести в конец транзакции получение уникального номера

(31) ты знал, ты знал!