2010-02-15 15 views
5

Tenemos un sistema en el que debemos usar el bloqueo pesimista en una entidad. Estamos utilizando hibernate, entonces usamos LockMode.UPGRADE. Sin embargo, no se bloquea."SELECCIONAR ... PARA ACTUALIZAR" no funciona para Hibernate y MySQL

  • Las tablas InnoDB son
  • Hemos comprobado que las obras de bloqueo correctamente en la base de datos (5.0.32), por lo que este error http://bugs.mysql.com/bug.php?id=18184 parece haber ningún problema.
  • Hemos comprobado que la fuente de datos incluye el parámetro autoCommit = false.
  • Hemos comprobado que el SQL hibernate (versión 3.2) genera incluye "PARA ACTUALIZAR".

Gracias,

+0

Hemos encontrado el mismo problema en los foros de hibernación, https://forum.hibernate.org/viewtopic.php?f=1&t=996902, pero no hay respuestas. –

+0

¿Cómo se dice que no se bloquea? y dado que hibernate ha generado la consulta adecuada, el problema está en la base de datos, supongo. – Bozho

+0

Porque el bloqueo pesimista se usa para generar una secuencia trnasactional y se duplican los valores duplicados. El uso del mismo SQL en una sesión interactiva se bloquea efectivamente, por lo que parece haber algún problema en la forma en que se realiza la conexión o en la sesión administrada. –

Respuesta

1

estoy corriendo en algo muy similar. Estoy usando la anotación @Transactional en Spring y estoy emitiendo una selección de actualización y el bloqueo de actualización no se está adquiriendo (tengo otros hilos que están emitiendo la misma selección para la actualización y he verificado que no están bloqueando una cerradura). Cuando obtengo explícitamente la sesión de Hibernate y ejecuto una startTransaction y me comprometo con el bloque de código, todo funciona.

Esto no me da una sensación cálida y difusa sobre las transacciones gestionadas en contenedores Spring.

1

Cuando tuve problemas similares, fue porque las transacciones gestionadas de Spring estaban mal configuradas. Revisa tu configuración Spring tx.

<tx:annotation-driven transaction-manager="txManager"/> 
<bean id="txManager" class="org.springframework.orm.hibernate.HibernateTransactionManager"> 
    <property name="sessionFactory" ref="sessionFactory" /> 
</bean> 

El hecho de que necesita autocommit = false también puede indicar que usted no está operando dentro de una transacción. ¿También obtiene excepciones de inicialización perezosas cuando intenta acceder a colecciones de uno a muchos?

La forma más directa que he encontrado para averiguar si el aspecto Spring tx está realmente funcionando es utilizar el depurador. Coloque un punto de interrupción en el método que emite el SQL FOR UPDATE. Upstack hasta que llegues a tu clase/método @Transactional. Debería ver el proxy de aspecto Spring en la próxima llamada en la pila de llamadas.

0

Últimamente he tenido un problema como este. Trabajábamos con gerentes de 2 tx porque teníamos bases de datos diferentes y el problema era que la transacción estaba usando el txmanager configurado en la otra base de datos y debido a eso en la conexión a la base de datos consultada no se deshabilitaba el modo de confirmación automática antes de realizar la selección para la actualización Usando el txmanager correcto resuelto eso. Espero que ayude a otros en el futuro.

Cuestiones relacionadas