Почему проверка NHibernate AutoFlush стоит так дорого?

Question

На практике мы находим, что стандартное NHibernate (v2.0 и 2.1) FlushMode = Auto является чрезвычайно дорогим. Анализ источника NHibernate показывает, что алгоритмы определения того, что необходимо очистить, основаны на грубой силе циклического прохождения всех объектов в сеансе, и это происходит для каждого запроса, выполняемого в транзакции.

В некоторых производственных сценариях с обновлениями для многих элементов с несколькими запросами мы видели процесс в 100 раз дольше с FlushMode = Auto по сравнению с FlushMode = Commit.

Любые мысли / советы / рекомендации по использованию FlushMode при выполнении «сложной» логики сеанса, включающей несколько обновлений, несколько запросов и т. Д.

Какие-нибудь идеи по оптимизации алгоритмов AutoFlush в nHibernate?

Answer 1

Эта медлительность является известной проблемой и отслеживается в NH как NH-1365 / GitHib Issue 857

В NH есть три режима промывки:

• FlushMode.Auto = Flush при необходимости (при фиксации и перед запросами, если необходимо). Это значение по умолчанию.
• FlushMode.Commit = сбрасывать только при фиксации транзакции NH
• FlushMode.Never = никогда не сбрасывать (пока не будет вызван Flush). Это будет по-прежнему идти в DB при вставке сущностей, которые используют собственный (идентифицирующий) генератор PK.