¿Por qué el control NHibernate AutoFlush es tan costoso?

Question

En la práctica, encontramos que el NHibernate predeterminado (v2.0 & 2.1) FlushMode = Auto es extremadamente caro. La revisión de la fuente NHibernate sugiere que los algoritmos para determinar lo que debe eliminarse dependen de la fuerza bruta del bucle a través de todas las entidades en sesión, y esto ocurre para cada consulta ejecutada en una transacción.

En algún escenario de producción con actualizaciones en muchos elementos, con múltiples consultas hemos visto el proceso 100 veces más largo con FlushMode = Auto en comparación con FlushMode = Commit.

Cualquier pensamientos/consejos/mejores prácticas para el uso de FlushMode al realizar la lógica sesión de 'complejo' que implica varias actualizaciones, etc. varias consultas

Ideas en la optimización de los algoritmos autoFlush en NHibernate?

Answer 1

Esta lentitud es un problema conocido y se hace un seguimiento en NH Jira como NH-1365

Hay tres modos de ras en NH:

• FlushMode.Auto = Flush cuando sea necesario (en cometer y antes de las consultas, si es necesario). Este es el predeterminado.
• FlushMode.Commit = vaciar en la transacción de NH solo
• FlushMode.Never = never flush (hasta que se llame a Flush). Esto será still go to DB en la inserción de entidades que usan generador PK nativo (identidad).