2010-02-15 6 views
5

Nous avons un système dans lequel nous devons utiliser le verrouillage pessimiste dans une entité. Nous utilisons Hibernate, donc nous utilisons LockMode.UPGRADE. Cependant, il ne se verrouille pas."SELECT ... FOR UPDATE" ne fonctionne pas pour Hibernate et MySQL

  • Les tables sont InnoDB
  • Nous avons vérifié que le verrouillage fonctionne correctement dans la base de données (5.0.32), donc ce bug http://bugs.mysql.com/bug.php?id=18184 semble y avoir aucun problème.
  • Nous avons vérifié que datasource inclut le paramètre autoCommit = false.
  • Nous avons vérifié que le hibernation SQL (version 3.2) génère inclut "FOR UPDATE".

Merci,

+0

Nous avons trouvé le même problème dans les forums Hibernate, https://forum.hibernate.org/viewtopic.php?f=1&t=996902, mais il n'y a pas de réponses. –

+0

Comment dire que ça ne bloque pas? et puisque hibernate a généré la requête appropriée, le problème est dans la base de données je suppose. – Bozho

+0

Parce que le verrouillage pessimiste est utilisé pour générer une séquence trasactionnelle et les valeurs de duplicaple sont généralisées. L'utilisation du même code SQL dans une session interactive est effectivement verrouillée, il semble donc y avoir un problème dans la manière dont la connexion est effectuée ou la session gérée. –

Répondre

1

Je suis en cours d'exécution en quelque chose de très similaire. J'utilise l'annotation @Transactional dans Spring et j'émets une sélection pour la mise à jour et le verrou de mise à jour n'est pas acquis (j'ai d'autres threads qui émettent la même sélection pour la mise à jour et ont vérifié qu'ils ne bloquent pas un verrou). Lorsque j'obtiens explicitement la session Hibernate et que je lance un beginTransaction et que je commets autour du bloc de code, tout fonctionne. Cela ne me donne pas un sentiment chaud et flou sur les transactions gérées par le conteneur Spring.

1

Lorsque j'ai eu des problèmes similaires, c'était parce que les transactions gérées par Spring étaient mal configurées. Vérifiez votre configuration Spring Spring.

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

Le fait que vous avez besoin autocommit = false peut également indiquer que vous ne fonctionne pas dans une transaction. Avez-vous également des exceptions d'initialisation paresseuses lorsque vous essayez d'accéder à des collections un-à-plusieurs?

La manière la plus directe que j'ai trouvée pour déterminer si l'aspect Spring tx fonctionne réellement est d'utiliser le débogueur. Mettez un point d'arrêt dans la méthode qui émet le code SQL FOR UPDATE. Upstack jusqu'à ce que vous atteigniez votre classe/méthode @Transactional. Vous devriez voir le proxy aspect Spring dans l'appel suivant dans la pile des appels.

0

Dernièrement, j'ai eu un problème comme celui-ci. Nous travaillions avec 2 gestionnaires tx parce que nous avions différentes bases de données et le problème était que la transaction utilisait le txmanager configuré pour l'autre base de données et à cause de cela sur la connexion à la base de données interrogée n'était pas désactivé le mode autocommit avant d'effectuer la sélection pour la mise à jour. En utilisant le bon txmanager résolu cela. J'espère que cela aidera les autres à l'avenir.

Questions connexes