дата+ тип документа = pk таблицы-счетчика

Если цикл не делать, то 5-6 документов из 4000 при тесте не вставляются, т.к. происходит ошибка, то самое задвоение

Так это PK, а не уникальный индекс. Уникальный индекс — это что ПОМИМО PK

Не должно такого быть.

Поясни (повтори, если уже было) пож почему?

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

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

и как же не проверяю результат вставки? там же try catch стоит. Не вставится, будет ошибка, попробуем ещё раз.

Всем привет. Есть задачка. Я её решил по своему, мои тесты прошли. Но мне сказали, что я с ней не справился, пока без уточнения подробностей. Мб кто подскажет другое решение? (своё пока не открываю) Есть табличка с кучей записей, и туда постоянно вставляют новые записи, очень часто. Каждая строка это документ, и у этого документа есть уникальный номер (varchar(32)), который формируется из даты его создания, его типа (А, Б, С, ...) и порядкового номера (int). И этот порядковый номер меняется от 1 до N в рамках дня создания(!) и типа документа(!). Т.е. номера, например, будут такие: 20170917/А-1 20170918/А-1 20170918/А-2 20170918/Б-1 20170918/С-1 20170918/С-2 20170918/С-3 20170919/А-1 ... Уникальный индекс на этот номер вешать нельзя по условию. При проверке запускается тест скрипт, четыре раза из четырёх разных сессий, который в цикле, с задержкой 50мс или около того, вставляет записи в эту табличку. Как реализовать заполнение такой таблички с формирлованием такого номера для каждого документа, но что бы не было задвоения этих номеров?

0. Поставить READ COMMITTED 1. Получить максимальное значение за день 2. id = максимальное значение + 1 3. Вставить запись с указанным id 4. Проверить количество совпадений, если больше одного, откатить транзакцию и повторить

5. Вызвать на дуэль того домового, который придумал запрет на уникальный индекс

В условии есть пункт "сессии не должны ждать друг друга". При READ COMMITTED это будет не так. Даже более того, там повесили тригер на инсерт, делающий задержку после каждого инсерта в 10 мс.

хочется плакать

я предлагаю оптимистичную

На оптимисте могут быть транзакции, зависшие в состоянии "я пытаюсь вставить запись"

Всем привет. Есть задачка. Я её решил по своему, мои тесты прошли. Но мне сказали, что я с ней не справился, пока без уточнения подробностей. Мб кто подскажет другое решение? (своё пока не открываю) Есть табличка с кучей записей, и туда постоянно вставляют новые записи, очень часто. Каждая строка это документ, и у этого документа есть уникальный номер (varchar(32)), который формируется из даты его создания, его типа (А, Б, С, ...) и порядкового номера (int). И этот порядковый номер меняется от 1 до N в рамках дня создания(!) и типа документа(!). Т.е. номера, например, будут такие: 20170917/А-1 20170918/А-1 20170918/А-2 20170918/Б-1 20170918/С-1 20170918/С-2 20170918/С-3 20170919/А-1 ... Уникальный индекс на этот номер вешать нельзя по условию. При проверке запускается тест скрипт, четыре раза из четырёх разных сессий, который в цикле, с задержкой 50мс или около того, вставляет записи в эту табличку. Как реализовать заполнение такой таблички с формирлованием такого номера для каждого документа, но что бы не было задвоения этих номеров?

вы хотите не ждать в mvcc, это взаимоисключающие параграфы

Etki, Ilia Zviagin, и другие - спасибо за инфу, переварю. Я пока убегаю. Завтра, если кому будет интересно, поделюсь какое решение предполагали авторы задачи.

он же де-факто пессимистичный

Там вся суть, что я вместо апдейта таблицы с хранлищем номером, произвожу инсерт в неё. А потом беру номер для нового документа так select @ItemIndexMax = max([ItemIndex]) from dbo.[Numbers] where [Date] = @Date and [TypeId] = @TypeId

понижать изоляцию(типа ставить возможным read uncommited) это же моветон

стало понятно. там mssql в примере?

Да

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

Какая изоляция транзакций, если там UPDATE ?