[NHibernate-Hispano] ciclo de vida de la session y de la transacción

[Nelo Pauselli]

Hola gente, como ya sabemos, se dice que en NH conviene trabajar
siempre dentro de una transacción. ¿por qué?

No estoy preguntando por qué hay que trabajar con transacciones, sino
porque tengo que extender la vida de mi transacción, en un ambiente
web por ejemplo, desde el BeginRequest hasta el EndRequest. o en MVC
desde el inicio de la acción (Action) hasta su final.

Ejemplo: tenemos una aplicación que, en un request:
1. consulta datos,
2. decide si hacer una modificación,
3. hace la modificación (en los objetos y los correspondientes SaveOrUpdates) y
4. armo la respuesta para el usuario consultando algunas propiedades
de los objetos

mi pregunta es ¿cual sería el problema de tener una transacción que
abarque solo el punto 3?

Saludos.
Nelo.

--
Para escribir al Grupo, hágalo a esta dirección: NHibernat...@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano

[José F. Romaniello]

El 5 de mayo de 2010 10:49, Nelo Pauselli <nelopa...@gmail.com> escribió:

Ejemplo: tenemos una aplicación que, en un request:
1. consulta datos,
2. decide si hacer una modificación,
3. hace la modificación (en los objetos y los correspondientes SaveOrUpdates) y
4. armo la respuesta para el usuario consultando algunas propiedades
de los objetos

mi pregunta es ¿cual sería el problema de tener una transacción que
abarque solo el punto 3?

Esta explicado en varios lugares, pero se me vino a la mente este:

http://nhprof.com/Learn/Alerts/DoNotUseImplicitTransactions

de donde extraigo textualmente:

Even if we are only reading data, we should use a transaction, because using transactions ensures that we get consistent results from the database. NHibernate assumes that all access to the database is done under a transaction, and strongly discourages any use of the session without a transaction.

Al principio también preguntaste por que hay que extender la vida de la transacción desde BeginRequest hasta EndRequest... Y eso es como que mezclas varias cosas. Session per requeest es un patrón y cada uno usa lo que le sirve, para muchas aplicaciones web eso resulta ser lo mejor...A lo que termino con esta pregunta:

¿Qué problemas estas teniendo o por que vos querrías que tu transacción sea mas corta?

[Fabio Maulo]

Ninguno; si estas seguro che en el punto 1 no se escribe nada, que la cache te funciona barbaro, que la base, como siempre necesita trabajar con transaciones, crea un transaction por cada query y te bancas el manejo de transaction hecho a manopla (no AOP).

Ahora ago yo la pregunta: cual es el problema que encontraste con que una transaction de NH abarque el tiempo de ejecuccion de una action del controler ?

Para mi tener [Transactional] y/o [Transactional(Ambient=true)] es muy comodo.

2010/5/5 Nelo Pauselli <nelopa...@gmail.com>

--
Fabio Maulo

[Nelo Pauselli]

José:
Si, se que está escrito por todos lados y justamente por eso la
pregunta de ¿por qué debe ser así?. Soy una de esas personas que no se
conforman con el "porque si". Justamente la idea del mail era
investigar ese porque (ademas, estuvo medio silenciosa la lista los
últimos días).

Fabio:
En el punto 1, 2 y 4 no se escribe en la db (y si se escribe está mal,
y hasta podría haber un control a nivel de eventos)
Me preocupa el: "que la cache te funciona barbaro" ¿que no podría
funcionar? así se a donde orientar los test (no te voy a decir que "me
tires una punta" porque se va a desviar la conversación).
¿los motores de db también crean transacciones para los select?...
igual no me afectaría en principio.

Problema 1: que necesito manejar un pool de transacciones a distintas
bases, alguna con NH (las de mi dominio), otras con directamente
ejecutando el INSERT o DELETE y hasta podría llegar a ser que tenga
que invocar servicios externos los cuales tendrían mecanismos
compensatorios para los rollback. Esto se llama transacciones
distribuidas ¿no?. Entonces: yo digo cuando empiezan las transacciones
y cuando terminan y como terminan.

Problema 2: que las excepciones de validación que da nhv al estar
integrado con nh, lo hace en el Flush ¿correcto?, que se haría antes
del Commit, al finalizar el Action ¿voy bien?. Yo preferiría poder
interceptar antes estas excepciones para enviar un mensaje al fronend
del usuario. Es decir, quisiera que el controller maneje la excepción
y envíe el mensaje a que el controller lanze una excepción.

Problema 3 (conflicto filosófico-personal): pienso, hasta ahora por lo
menos, que la transacción es un concepto de negocio y no me agrada del
todo el hecho de transferirle la responsabilidad de esto a la
infraestructura, sino que espero de esta que me de el soporte para
decidir, desde el negocio, cuando hacer el begin, commit o rollback de
una transacción.

Nelo.


2010/5/5 Fabio Maulo <fabio...@gmail.com>:

[Edgar Ramos]

El punto de vista de Nelo en el punto 3 tambien lo pude apreciar en
esta propuesta

http://msdn.microsoft.com/es-es/architecture/default.aspx, guia de
arquitectura en n capas orientadas al dominio (DDD), pagina 224,
pueden ahondar un poco mas en este tema por favor

saludos