-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Changement de référence d'une collection (hibernate 1.3.1)
PostPosted: Mon Jun 08, 2009 4:20 am 
Newbie

Joined: Mon Jun 08, 2009 3:48 am
Posts: 2
Bonjour,

C'est la deuxième fois que je rencontre un problème avec la lib hibernate qui me change la référence de mes Set au saveOrUpate(). Plus précisément lorsque je debug et que je met un arrêt sur le 'modify' de mon HashSet, je me rend compte que ce n'est pas mon applicatif qui redéfini le Set mais bien hibernate pour le remplacer par un PersistenceSet (si je met en commentaire une des listes il présente le pb sur le Set suivant), le problème c'est qu'ensuite il considère que la référence a été changée et il part en exception avec indifféremment les messages suivants:

Don't change the reference to a collection with cascade="all-delete-orphan": xxx.bo.DocumentRBO.formulairesR

ou

identifier of an instance of xxx.bo.ReleveDeGestionBO was altered from 1015809 to 1015810

Comme précisé dans le titre je me trouve en version 1.3.1.

Je suis dans un contexte applicatif assez complexe avec multi héritage voici un extrait de mon hbm contenant un des set incriminé :
<hibernate-mapping>
<class name="xxx.bo.DocumentRBO" table="DOCUMENT_R" abstract="true"
proxy="xxx.bo.IDocumentRBO">
<id name="id" type="java.lang.Long">
<column name="PK_SEQ" />
<generator class="sequence">
<param name="sequence">SEQ_DOCUMENT_R</param>
</generator>
</id>

<discriminator column="DIC_TYPE_DOCUMENT_R" type="java.lang.String" />

<property name="dateCreation" column="DATE_CREATION" />
<property name="acteurCreation" column="ACTEUR_CREATION" />

<property name="dicStatutDocument" column="DIC_STATUT_DOCUMENT_R" />
<property name="dateStatut" column="DATE_STATUT" />
<property name="fkDocument" column="FK_DOCUMENT_SEQ" />
<property name="numero" column="NUMERO" />
<property name="dicTypeDocumentR" column="DIC_TYPE_DOCUMENT_R" insert="false" update="false"/>

<property name="fkNatureDocument" column="FK_NATURE_DOCUMENT_SEQ" />
<property name="fkElementStructureSupport" column="FK_ELT_STRUCTURE_SUPPORT_SEQ" />

<!-- attributs IRuptureBO -->
<property name="jobId" column="JOB_ID" />
<property name="niveauRupture" column="NIVEAU_RUPTURE" />
<property name="ruptureId" column="RUPTURE_ID" />


<set name="formulairesR" table="FORMULAIRE_R" cascade="all-delete-orphan" inverse="true">
<key column="FK_DOCUMENT_R_SEQ" />
<one-to-many class="xxx.bo.FormulaireRBO" />
</set>


<set name="envoiDocumentR" table="ENVOI_DOCUMENT_R" cascade="all-delete-orphan" inverse="true">
<key column="FK_DOCUMENT_R_SEQ" />
<one-to-many class="xxx.bo.EnvoiDocumentRBO" />
</set>

</class>
</hibernate-mapping>

Pour info : La première fois que le problème avait été rencontré c'était dans le cas d'un create() d'un objet qui dans la même transaction était concerné par une requête SELECT qui jointait dessus, sur le onFlush() du select() hibernate changeait ma référence et lors du dernier save() de la transaction j'avais une exception, cela avait été résolu en créant mon objet en JDBC et en faisant charger l'objet du 'create' par hibernate pour lui faire croire que c'était un update d'un objet déjà existant, et j'étais en environnement monoThread.

Le problème actuel est un petit peu différent car il ne se produit qu'en environnement multithreadé lors de l'execution d'un batch et n'est apparu que depuis la modification du code dans des soucis d'optimisations (les threads ne travaillent plus sur du code qui prenait bcp de temps). Je tiens a précisé que le code est threadSafe et qu'aucun objet ni set n'est partagé entre les threads, à l'exception d'un objet ElementValorise qui lui est rattaché aux objets créés de nos threads (chargé dans chaque thread avec un load() pas de get()).
Les objets sont instrumentés. Le modèle (hbm) ne peut pas trop évoluer.

Il est inutile et trop fastidieux que je vous mette le reste du code qui ne fera que noyer le pb, mes questions sont donc les suivantes:
-Existe t'il dans cette version un bug connu d'hibernate concernant ce changement de Set détecté ensuite comme une modification incorrect par hibernate. Dans ce cas y a t-il un moyen de contourner?
-Quel est le mécanisme d'hibernate pour gérer le dirty des collections après la persistence de celle-ci?

Merci d'avance pour vos réponse...


Top
 Profile  
 
 Post subject: Re: Changement de référence d'une collection (hibernate 1.3.1)
PostPosted: Mon Jun 15, 2009 10:20 am 
Newbie

Joined: Mon Jun 08, 2009 3:48 am
Posts: 2
Mon pb avait été résolu, je viens mettre un ptit com.

En fait le pb auquel je faisais référence n'avait rien à voir avec le pb détaillé ici. J'ai été induit en erreur par le caractère aléatoire de l'execution en multithread. Suivant le parrallélisme d'execution de chaque thread on peut se retrouver avec un ConcurrencyException ou un id modifié ou une collection modifée etc, cependant l'erreur à l'origine de tout ca c'est simplement un objet partagé à tord entre plusieurs thread en écriture ou update. Le context applicatif étant tellement complex cela n'a pas sauté aux yeux.

Conseil pour identifier ceci rapidement, mettre seulement 2 thread, mettre un poin d'arrêt sur tous les types d'exception aléatoire et les configurer en stoppant non pas le thread mais la JVM. Lorsqu'il s'arrete regarder simplement l'id java de vos objets utilisés par les 2 threads et regarder ceux qui ont des id identiques. Dans notre cas on aurait jamais du avoir de partage, cependant il se peut que vous ayez besoin de réutiliser des objets (en écriture ou update) auquel cas il faut impérativement synchroniser l'objet, cependant attention au niveau des perfs car cela créé des points de contention.
Dans le cas de lecture penser à forcer le lazyloading car un objet chargé dans une session d'un thread sera détaché dans une autre...

hope it helps...


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.