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...
|