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 <[email protected]>: > 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 <[email protected]> >> >> 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: >> [email protected] >> Para más, visite: http://groups.google.com/group/NHibernate-Hispano > > > -- > Fabio Maulo > > -- > Para escribir al Grupo, hágalo a esta dirección: > [email protected] > Para más, visite: http://groups.google.com/group/NHibernate-Hispano -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
