2011-11-14 8 views
8

Estoy depurando nuestra aplicación web. Está configurado para crear un bean DataSourceTransactionManager y también un bean HibernateTransactionManager en el inicio. Esto no es intencional sino que es causado por una dependencia de terceros. El efecto parece ser benigno. Lo que estoy viendo a través de la depuración es que cuando persistimos en un objeto a través de un DAO basado en Hibernate, se invoca el DataSourceTransactionManager y no el HibernateTransactionManager (los beans se llaman 'transactionManager'). El Spring Javadoc implica (creo, volver a leerlo ahora) esto está bien para los recursos locales, que es nuestra situación. Es decir. no es un entorno basado en JTA distribuido.¿Está bien utilizar DataSourceTransactionManager para persistencia ORM en lugar de HibernateTransactionManager?

Mi pregunta es: ¿hay algún impacto negativo de no utilizar el HibernateTransactionManager para la persistencia basada en ORM. Puedo cambiar la configuración para hacer que el HibernateTransactionManager se use a través de un calificador en la anotación @Transactional en nuestros DAO.

Las cosas funcionan bien en pruebas unitarias simples, configuración de prueba de integración, pero estoy más preocupado por escalar a volúmenes de producción completos cuando tendremos miles de usuarios y un alto nivel de concurrencia.

TIA, Espero que esto no sea demasiado oscuro.

Spring 3.0.x BTW.

Esto está en Spring 3.1 docs.

Sec 11.9 "Soluciones a los problemas comunes".

Utilice la implementación PlatformTransactionManager correcta basada en su elección de tecnologías y requisitos transaccionales.

Respuesta

6

Esto me parece erróneo y causará problemas. Sin el administrador hibernate txn, todas las llamadas realizadas a HibernateOperations estarán fuera de una transacción y en una sesión separada, posiblemente mediante el autocompromiso. Por lo que puede parecer que todo está bien cuando ocurre un error, es posible que los cambios que esperaría que se retrotraigan no lo sean.

intente lo siguiente para comprobar

  • comienzan tran
  • salvar algo
  • tiro excepción
  • cometer

Compruebe si el 'algo' aparece en la base de datos o no.

Otra comprobación sería

  • comenzar tran
  • carga algo
  • acceso a una relación con otro objeto de algo y acceder a una propiedad (no el pk) de este objeto relacionado

Puede encontrar que la última llamada causa una excepción ya que la sesión no se mantuvo abierta desde la carga porque el txn adjunto no está gestionado por el administrador de txn de hibernación.

+0

+1 Hmm. interesante. gracias. probará una de estas pruebas. Lo que veo es que las llamadas DAO se llevan a cabo dentro de las transacciones, y el DAO llama a getSession(), por lo que Spring SessionFactoryUtils devuelve una nueva sesión y todo parece estar bien. pero como dices, ¿con qué frecuencia recordamos desandarnos? –

+4

Bueno. He intentado esta prueba. Causó una excepción después de guardar, con Hibernate tx mgr se guardó el guardado. Con DataSourceTransactionManager no fue así. –

+0

¿Podría proporcionar el documento oficial que respalda su palabra "Sin el administrador hibernate txn todas las llamadas realizadas a HibernateOperations estarán fuera de una transacción y en una sesión separada"? Estoy usando DataSourceTransactionManager + Hibernate. – DerekY

Cuestiones relacionadas