Приветствую уважаемые коллеги !

Платформа 1С: 8.3.9.2033
СУБД: Postgres (текущий последний релиз)

Предмет вопроса:
    Пусть есть чистая конфигурация в режиме управляемых блокировок, в ней один справочник "Контрагенты", у которого два реквизита "ИНН" и "КПП". Эти поля указанны как поля блокировки данных.
    В конфигурации есть веб-сервис, который вызывается из других конфигураций и записывает нового (или обновляет) существующего контрагента. Сервисом единовременно пользуются несколько клиентов.
    В модуле контрагента "ПриЗаписи" выполняется запрос, который ищет по "ИНН" и "КПП" контрагентов, и если существуют контрагенты с такими значениями "ИНН" и "КПП", клиент веб-сервиса получает отказ в записи, т.к. в рамках задачи контрагенты должны быть уникальны.

    1. Одновременно начинаются две транзакции (так уж и одновременно ?) и пытаются записать одинакового ("ИНН", "КПП") контрагента.
    2. В обработчике события "ПриЗаписи", т.е. в транзакции выполняется запрос на поиск контрагентов, оба запроса успевают завершится до того, как завершится одна из двух транзакций, соответственно дубликатов не будет найдено ни в одной транзакции и в справочник попадут дубликаты ?

    Вопрос: я ошибаюсь ? И как дела обстоят в НЕ версионых СУБД ?

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

(0) Эксклюзивная блокировка данных по ИНН и КПП до начала запроса вам должна помочь.

Тип СУБД значения не имеет.
В методе вебсервиса:
Начать транзакцию
Установить блокировку по инн и кпп
Сделать запрос по инн и кпп, найти ссылку
Если найдено получить, иначе создать объект
Заполнить остальные данные
Записать объект
Зафиксировать транзакцию

И ни каких действий "ПриЗаписи", и ни каких отказов в записи клиенту.

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

блокировка  по инн и кпп блокирует на запись весь справочник.

(4)>>блокировка  по инн и кпп блокирует на запись весь справочник.

?? Это же неправда.

(2) я так и реализовал ) Только при создании или изменении у объекта реквизитов по которым ставится блокировка нужно два раза читать данные, сначала проверка и если разрешено, только тогда блокировать и записывать/обновлять. Минимальные ожидания на блокировках.
(4) очень интересно, а на практике прибывали ? Как проходит обновление конфигурации например ? И про блокировку всего справочника, вы наверное имели ввиду автоматическую блокировку, если иначе, то ваше утверждение не верно !
(3) уникальность контролируется не только при записи через веб-сервис, но при записи объекта в своей базе, поэтому такое решение.

(6)>>сначала проверка и если разрешено, только тогда блокировать..

это ошибка :)

(7) это почему ?

(8)потому что пока не стоит блокировка, проверять не имеет смысла.

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

Боже мой.. Может я открою вам великую тайну, но давайте начнем с того, что даже исключительная блокировка чтение не блокирует )))
Она блокирует установку другой блокировки.

А вообще, по тому что вы тут излагаете по этому вопросу..

Читать, только читать! Писать вам еще рано.

(5) Это бред этого гражданина. забаним его.

(11) Забей. У него чтение проходит нормально, а затем, при попытке поставить блокировку идет ожидание на блокировке и все по стандарту. Дефакто, у него просто лишнее чтение а механизм работает