Быстрое получение уникального числового значения без блокировок

Быстрое получение уникального числового значения без блокировок

Решение созрело такое:1. Создается табличка прямо в БД 1С вида:(для MS SQL Server)CREATE TABLE [dbo].[zbarcodes]( [ID] [bigint] IDENTITY([НАЧАЛЬНОЕЗНАЧЕНИЕСЧЕТЧИКА],1) NOT NULL, CONSTRAINT [PK_zbarcodes] PRIMARY KEY CLUSTERED ( [ID] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]) ON [PRIMARY]

[НАЧАЛЬНОЕЗНАЧЕНИЕСЧЕТЧИКА] - заменить на число, например 20000000000 - первый шк в системе (или другое число - последнее в Вашей учетной системе, если хочется продолжить текущую нумерацию)

2. Создаем Процедурку в общем модуле с выполнением на сервере (для УФ)

//Процедура получения уникального штрихкода (у нас используется Code 128 - без контрольных символов)//Параметры://Организация - можно сделать таблицы на каждую организацию - и получать по организации имя таблицы в БД из ЗначенияСвойствОбъектов//СтруктураПараметров - параметры подключения к БД SQL через ADO

Функция ПолучитьНовыйШтрихкод(Организация, СтруктураПараметров) Экспорт

Соединение= Новый COMObject("ADODB.Connection"); Соединение.ConnectionString = "Driver=;Server ;UID ;pwd ;Database Возникла ошибка подключения к базе"); #КонецЕсли Соединение=""; Возврат Неопределено; КонецПопытки;

ТекстЗапроса="INSERT into zbarcodes DEFAULT VALUES"; Соединение.Execute(ТекстЗапроса);

ТекстЗапроса="SELECT @@IDENTITY"; Выборка=Соединение.Execute(ТекстЗапроса);

Выборка.Close(); Выборка ="" Соединение = "";

В итоге все забыли что такое блокировки при присвоении новых штрихкодов, и обеспечена уникальность штрихкода, + скорость получения значения!

Специальные предложения
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти

(4) kostyaomsk, С константой вариант тоже не прошел - по причине блокировок! Пробовали! С Кэшем интересно будет попробовать.

  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти
  • Скопировать ссылку
  • Перейти

Мне кажется некорректным сравнение производительности между полноценным регистром сведений, который хранит явно больше информации с голой таблицей из цифр.

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

Наверно, для сравнения лучше подойдет объект попроще - константу, например, предлагали в комментариях. Или 1 элемент справочника - его блокировать, увеличивать реквизит на 1 и записывать.

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

  • Скопировать ссылку
  • Перейти

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

тут уж как настроите подключение к БД - если копия - то данные о БДSQL можно получать из настроек БД 1C а копии однозначно и давно создаются при помощи SQL Backup. вряд ли я смогу 300Gb выгрузкой - загрузко данных копировать)) - так что табличка в ажуре и актуальна!

Константа отпала сразу на основе начала реальной работы!

  • Скопировать ссылку
  • Перейти

(15) serferian, верно, поэтому я предлагаю использовать объект попроще, чем РС именно для задачи быстрого получения следующего номера. Пусть это будет 1 элемент справочника, в реквизите которого хранится последнее выданное число. Раз пропуски в номерах возможны => можно не связывать эту транзакцию с остальной логикой => читаем значение, делаем инкремент, записываем без пауз, а уже потом используем записанное значение. Я думаю, будет ненамного медленнее и особых блокировок не возникнет, зато все сделано средствами платформы и не добавляет мучений сисадминам, легко используется в остальных механизмах платформы.

📎📎📎📎📎📎📎📎📎📎