Download Documentación de referencia de Hibernate

Conversaciones largas
Puede extender el ámbito de una Session y transacción de la base de datos hasta que "se
ha presentado la vista". Esto es bastante útil en aplicaciones de servlet que utilizan una fase
de entrega separada después de que se ha procesado el pedido. El extender la transacción
de la base de datos hasta que la entrega de la vista se encuentre completa es fácil de lograr
si implementa su propio interceptor. Sin embargo, no se logra fácilmente si depende de EJBs
con transacciones administradas por el contenedor. Una transacción se completará cuando un
método EJB retorna, antes de que pueda empezar la entrega de cualquier vista. Vea el sitio web
de Hibernate y el foro para encontrar consejos y ejemplos sobre este patrón de sesión abierta
en vista.
12.1.2. Conversaciones largas
El patrón sesión-por-petición no es la única forma de diseñar unidades de trabajo. Muchos
procesos empresariales requieren una serie completa de interacciones con el usuario
intercaladas con accesos a la base de datos. En aplicaciones empresariales y web no es
aceptable que una transacción de la base de datos abarque la interacción de un usuario.
Considere el siguiente ejemplo:
• Se abre la primera pantalla de un diálogo. Los datos que ve el usuario han sido cargados en
una Session en particular y en una transacción de la base de datos. El usuario es libre de
modificar los objetos.
• El usuario hace click en "Guardar" después de 5 minutos y espera que sus modificaciones se
hagan persistentes. También espera que él sea la única persona editando esta información y
que no ocurra ningún conflicto en la modificación.
Desde el punto de vista del usuario, llamamos a esta unidad de trabajo, una larga conversación
o transacción de aplicación. Hay muchas formas de implementar esto en su aplicación.
Una primera implementación ingenua podría mantener abierta la Session y la transacción de la
base de datos durante el tiempo para pensar del usuario, con bloqueos en la base de datos para
prevenir la modificación simultánea y para garantizar el aislamiento y la atomicidad. Esto es un
antipatrón, ya que la contención de bloqueo no permitiría a la aplicación escalar con el número
de usuarios simultáneos.
Tiene que usar varias transacciones de la base de datos para implementar la conversación. En
este caso, mantener el aislamiento de los procesos empresariales se vuelve una responsabilidad
parcial de la capa de la aplicación. Una sóla conversación usualmente abarca varias
transacciones de la base de datos. Será atómica si sólo una de estas transacciones de la base de
datos (la última) almacena los datos actualizados. Todas las otras simplemente leen datos (por
ejemplo, en un diálogo de estilo-asistente abarcando muchos ciclos petición/respuesta). Esto es
más fácil de implementar de lo que suena, especialmente si usa las funcionalidades de Hibernate:
• Versionado automático - Hibernate puede realizar un control automático de concurrencia
optimista por usted .Puede detectar automáticamente si ha ocurrido una modificación
simultánea durante el tiempo para pensar del usuario. Chequee esto al final de la conversación.
187