Événement de création simultanée

Question

J'utilise JBoss 5.1.0 GA avec Hibernate et j'essaie maintenant de permettre au cache de second niveau. J'ai ajouté les propriétés suivantes à ma configuration de mise en veille prolongée.

<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.jbc2.MultiplexedJBossCacheRegionFactory"/>
<property name="hibernate.cache.jbc2.query.localonly" value="true"/>
<property name="hibernate.cache.region_prefix" value="my_prefix" />

Et j'ai des entités que j'annotés changer souvent attends avec les éléments suivants:

@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)

Ceci est basé sur ma compréhension de la documentation .

L'application se déploie avec succès sans peur des messages à la recherche (par exemple WARN ou les messages d'erreur dans le flux de journal). Pendant une courte période de temps, je vois la mise en cache de travail (j'utilise les statistiques Hibernate pour voir ce sujet), mais après un peu de temps je me traces de pile de la forme (même lorsque vous êtes connecté en tant qu'utilisateur unique sans accès à distance que ce soit):

  

"Transaction a tenté de créer   MyClass à nouveau. Il a déjà été   créé depuis cette transaction   commencé, par un autre (peut-être à distance)   transaction. Nous avons un concurrent   événement de création "

Après par une trace de pile géante qui trace finalement revenir à une requête nommée que j'ai fait qui a la forme suivante:

SELECT x FROM X WHERE x.deleted = false

La requête nommée n'a pas d'annotations supplémentaires pour la mise en cache.

Des conseils sur la façon de résoudre ce problème serait grandement apprécié.

Answer 1

Quelques questions d'abord:

1. Est-ce cette exception se propage à votre application? Je veux dire, êtes-vous affecté par cela, ou vous êtes juste préoccupés par le message dans le journal?
2. sont-ils tous vos entités annotées avec la stratégie Transactionnelle, ou seulement quelques-uns d'entre eux?
3. Votre requête récupère les objets avec avidité d'une autre classe tirées par les cheveux?

Je dirais que la meilleure chose que vous puissiez faire est maintenant pour permettre DEBUG (ou peut-être même TRACE) enregistrement pour les opérations de cache: log4j.logger.org.hibernate.cache=debug Cela vous dira exactement ce que Hibernate fait. I suspect que Hibernate tente de mettre un objet dans le cache, et de le faire à nouveau une fois qu'il voit le même objet au cours de la même session (peut-être dans le cadre de l'arbre d'un autre objet). Il y avait un problème d'horodatage pour cache de requêtes il y a quelque temps, et le même problème pourrait se produire ici. Par exemple:

Object A#1
 -- Object B#1

Object A#2
 -- Object B#1

Mais encore une fois, il est un peu difficile de prédire ce que la solution est sans savoir ce que le problème serait. Et je crains que seul journal Hibernate peut vous dire ce que le problème est vraiment.

PS:. Cela a été destiné à être affiché comme commentaire, mais cela était tout simplement trop long pour elle

Answer 2

Avez-vous essayé CacheConcurrencyStrategy.NONSTRICT_READ_WRITE? J'ai lu les docs beaucoup de fois et je ne sais pas exactement ce qu'il faut choisir, mais semble fonctionner très bien pour mes projets. Je suppose que le CacheConcurrencyStrategy.TRANSACTIONAL est trop sûr et éviter les performances du cache dans certaines circonstances.