Генератор NHibernate HiLo генерирует дубликаты идентификаторов

У меня есть приложение, работающее на nHibernate v4.0.4.4000 - оно работает на трех независимых веб-серверах. Для генерации ID я использую стандартную реализацию HiLo по умолчанию (уникальный идентификатор через таблицы).

Иногда он создает дубликат идентификатора при сохранении новых объектов со следующей трассировкой стека:

SessionFactory настроен на использование SnapshotIsolation, DB устанавливается на уровне совместимости 2008 (100)

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

Согласно профилировщику NHibernate, SQL-прогон против сервера для значений hilo:

Что мне не хватает? Не следует ли защищать HiLo от дубликатов?

EDIT: повторяющиеся идентификаторы выполняются не только на одной таблице, но и в таблицах с очень частыми вставками и удалениями. Вышеприведенный код был самым простым среди подозреваемых и очень прост - он только .Get() родительский, чтобы проверить, что он там, а затем создает и вызывает .Save() в новом сущности вместе со строкой контрольного журнала (в которой используется сценарий события PostInsert в nHibernate).

EDIT2: Id-Mapping для вышеуказанного типа (используется для всех объектов):

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

Ответы

Ответ 1

Я понял проблему. Оказывается, это не имело никакого отношения к Id.

Как часть инструкции insert, мы обновляем вторичную таблицу, которая управляет числовой серией. Проблема возникает, если эта вторичная таблица испытывает ошибку изоляции моментального снимка - поскольку все обрабатывается внутри SQLCommandSets внутри nHibernate - ошибка создает пузырьки цепи с ошибочным описанием.

Ответ 2

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

Вы либо пропускаете сеансы nhibernate, и вы получаете состояние скрытой гонки, когда происходит генерация фактического идентификатора на данном экземпляре (поскольку идентификация в базе данных изолирована транзакцией). Предполагается, что экземпляр приложения тот же успешно вставлен {ID = 123}, а затем попытался вставить другой объект с {ID = 123}. Вы можете трассировать вставки обратно в экземпляры приложений, чтобы убедиться, что дублирование вложений происходит в одном экземпляре. Я не очень уверен, действительно ли этот сценарий правдоподобен во всей цепочке конвейера NHibernate, но ISession не является потокобезопасным (и это известный факт). Вы говорите, что это работает уже 4 года (хотя вы не упоминаете, что ошибка была там так долго), поэтому, возможно, недавняя фиксация ввела это поведение (коллекции .AsParallel() было бы достаточно, чтобы вызвать ее Я верю)?

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

var entity123 = Get (123)
var entity123 = entity123.Clone() или ISession.Evict(entity123).
где-то вдоль строки, которую вы вызываете SaveOrUpdate (entity123) (или, что еще хуже, для отслеживания вы добавляете ее в ссылочную коллекцию с правилами каскадного сохранения)
NHibernate видит объект с управляемым объектом с идентификатором на месте, пытается вставьте его.

В некоторой более ранней версии NHibernate я видел это поведение с неидентичными вставками.

Вышеупомянутое может также произойти с методом bad/dumb factory, который также копирует идентификатор.

Проследить эту проверку, если вставляются параметры SQL (для log4net, которая была бы записью NHibernate.SQL с отладкой, хотя я думаю, что профилировщик NHibernate также обнаружит это) сопоставить существующие значения столбца строки. Если они точно совпадают, то может произойти нечто подобное выше. Если они частично совпадают, возможно, вы делаете частичные копии сущностей, и он также случайно копирует идентификатор.

Ответ 3

что, если вы только что изменили на:

postPreview.Index = index+1;