El logro de NHibernate anidada Transacciones Comportamiento

Question

Estoy tratando de lograr algún tipo de comportamiento de la transacción anidada utilizando control de transacciones de NHibernate y opciones FlushMode, pero las cosas se pusieron un poco confuso después de leer demasiado, por lo que cualquier confirmación de los hechos enumero a continuación será muy útil.

Lo que quiero es abrir una transacción grande que se divide en pequeñas transacciones. Imagine el siguiente escenario:

• TX1 abre un TX y se inserta registro de una persona;
• TX2 abre un TX y actualiza el nombre de esta persona a P2;
• compromete TX2;
• TX3 abre un TX y actualiza el nombre de esta persona a P3;
• rollbacks TX3;
• compromete TX1;

Me gustaría ver NH enviar el INSERT y UPDATE TX2 a la base de datos, simplemente haciendo caso omiso de lo que TX3, ya que se deshace.

He intentado utilizar FlushMode = Nunca, y sólo el lavado de la sesión después de que comience el correcto / Commits / Rollbacks han exigido, pero NH Siempre actualizar la base de datos con el estado final del objeto, independiente de confirmaciones y reversiones. ¿Eso es normal? ¿El NH realmente hace caso omiso de control transaccional cuando se trabaja con FlushMode = Nunca?

También he intentado usar FlushMode = Confirmar y openning las transacciones anidadas, pero descubrí que, debido a ADO.NET, las transacciones anidadas son, en realidad, siempre la misma transacción.

Tenga en cuenta que yo no estoy tratando de lograr un comportamiento "todo o nada". Busco más que una forma de punto de salvaguarda de trabajo. ¿Hay una manera de hacer que los puntos de retorno () con NH?

Gracias de antemano.

Filipe

Answer 1

Sólo para no dejar esta cuestión abierta para siempre, voy a publicar la solución que hemos adoptado.

Tenemos una unidad de trabajo como contenedor que gestiona el comportamiento de la transacción anidada. Dependiendo del tipo de tratamiento que queremos, se crea (o no) las nuevas sesiones. Por ejemplo:

• Continuar en caso de error: si queremos que, aunque en un error de transacción de las otras confirmaciones, el contenedor UoW ??utiliza diferentes sesiones para cada "transacción" y elimina todos los tx en el final de su trabajo;
• Rollback en caso de error: si queremos que en una reversión de sesiones (debido a un error o una reversión de negocios) cada otra transacción es cancelada, el contenedor UoW ??utiliza la misma sesión para todas las transacciones anidadas y revierte todo el mundo en el final.

Es importante decir que la "transacción" que este manipula UoW no es la transacción NH (ADO.NET) directamente. Hemos creado una abstracción de una transacción por lo que los códigos de manipulación "votos" si nuestra transacción podría estar comprometidos o se deshace, pero la verdadera acción solo ocurre en el final de todo, en base a la estrategia de error seleccionado.

Sabemos que este uso no es muy común y sólo entra en escenarios específicos (en nuestro caso se trata de un escenario de integración con el procesamiento por lotes), por lo que voy ahora código postal. Si alguien piensa que esta aplicación puede ayudar, por favor, envíeme un mensaje y estaré encantado de compartir el código.

Saludos,

Filipe

Answer 2

NHibernate no soporta transacciones anidadas. Cada ISession puede tener como máximo una transacción activa. No estoy seguro de lo que, estamos tratando de lograr debido a su situación de ejemplo no tiene sentido para mí. La comisión de transacción 1 después de la inserción tendría el mismo efecto.