bug #6687
closedMultiple representations of the same entity merge problem
100%
Description
The eu.etaxonomy.vaadin.mvp.AbstractCdmEditorPresenter<DTO extends CdmBase, V extends ApplicationView<?>>
class uses short running sessions. Modified entities must thus be merged into the new Session before they can be saved.
In some cases however the merge fails with an IllegalStateException like the one that is shown below. The below exception was thrown after while merging a BotanicalName instance whereas the Person (id:10) is at the same time the combinationAuthor and the author of the associated nomenclaturalReference :
Caused by: java.lang.IllegalStateException: Multiple representations of the same entity [eu.etaxonomy.cdm.model.agent.Person#10] are being merged. Detached: [Cheng-Long Shaw]; Managed: [Cheng-Long Shaw] at org.hibernate.event.internal.EntityCopyNotAllowedObserver.entityCopyDetected(EntityCopyNotAllowedObserver.java:37) at org.hibernate.event.internal.MergeContext.put(MergeContext.java:245) at org.hibernate.event.internal.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:304) at org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:170) at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:850) at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:832) at org.hibernate.engine.spi.CascadingActions$6.cascade(CascadingActions.java:260)
This problem is a known issue of hibernate: Hibernate ORMHHH-9106 - Multiple representations of the same entity cannot be merged using cascade=merge
The chosen solution is to use the ConversationHolder
to implement the session-per-conversation pattern in that way that a independent per view conversations exists for the whole lifetime of a eu.etaxonomy.vaadin.mvp.AbstractView. This covers read only view as well as popup editors implementing eu.etaxonomy.vaadin.mvp.AbstractPopupView
. By this we completely avoid the merging problem since all instances are guaranteed to be loaded in the same session.
OLD REJECTED SOLUTION DESCTIPTION BELOW
Since Hibernate 4.3.6 there is a hibernate property to work around this problem:
<prop key="hibernate.event.merge.entity_copy_observer">allow</prop>
When using hibernate.event.merge.entity_copy_observer=allow
you must be aware of the risks and possible side effects, please refer to the patagraphs RISKS OF MERGING ENTITY COPIES and RECOMMENDATIONS in the above linked issue.
According to the recommendation given in the hibernate issue we should set hibernate.event.merge.entity_copy_observer=log
and add the following lines to the log4j.properties, in development environments (~/.cdmLibrary/log4j.properties)
# Keep this on DEBUG for developing cdm-vaadin applications !!! # # logs merging of multiple representations of the same entity, please refer to # https://dev.e-taxonomy.eu/redmine/issues/6687 # for further details log4j.logger.org.hibernate.event.internal.EntityCopyAllowedLoggedObserver=DEBUG
Related issues
Updated by Andreas Kohlbecker almost 7 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 50
Applied in changeset cdm-vaadin|754d57e3aa08265ad9b4502bf104614a5c49c574.
Updated by Andreas Kohlbecker almost 7 years ago
Hi Andreas,
diese Lösung (hibernate.event.merge.entity_copy_observer=allow
) könnte ziemlich riskant sein. Wir haben dieses Problem ja regelmäßig im TaxEditor und es stellt sich eigentlich immer heraus, dass es eine Lösung gibt, die ohne diesen Workaround auskommt. Entscheidend dabei scheint mir zu sein, dass eben von Clientseite immer sichergestellt wird, dass wirklich nur exakt 1 Objekt für die gleiche id in die Session gemerged wird. Wenn das nicht der Fall ist, läuft an anderer Stelle etwas unsauber und man läuft v.a. Gefahr, 2 Objekte mit verschiedenen Zuständen in die gleiche Session zu mergen mit undefinierten Folgen.
Katja und auch Patrick haben sich mit diesem Problem schon viel auseinandergesetzt und eigentlich immer eine Lösung gefunden. Wichtig ist v.a. glaube ich, dass der Client, sofern er außerhalb einer Session arbeitet, ebenfalls dafür sorgt, das Objektidentität besteht, also das, was Hibernate innerhalb einer Session automatisch übernimmt, auch macht. Cherian hat das für den Editor so implementiert. Das sollten andere Clients m.E. schon aus eigenem Interesse auch immer versuchen.
Viele Grüße,
Andreas M.
Updated by Andreas Kohlbecker almost 7 years ago
- Status changed from Resolved to In Progress
Hi Andreas,
I fully agree, this is too risky for a long term solution, but I haven't found a solution to the probelm in cdm-vaadin so far. Therefore I decided to use the workaround committed with cdm-vaadin|754d57e3
Andreas
Updated by Andreas Kohlbecker over 6 years ago
- Target version changed from Release 4.8 to Release 4.9
Updated by Andreas Kohlbecker over 6 years ago
The solution that has been chosen is to use the ConversationHolder
to implement the session-per-conversation pattern in that way that a independant per view conversations exists for the whole lifetime of a eu.etaxonomy.vaadin.mvp.AbstractView
. This covers read only view as well as popup editors implementing eu.etaxonomy.vaadin.mvp.AbstractPopupView
.
Updated by Andreas Kohlbecker over 6 years ago
- Status changed from In Progress to Resolved
Applied in changeset cdm-vaadin|fe785c1e9ea0a833a9edae2bcb6196851a205764.
Updated by Andreas Kohlbecker over 6 years ago
- Status changed from Resolved to Closed
- % Done changed from 50 to 100
Updated by Andreas Kohlbecker over 6 years ago
- Related to bug #7047: Vaadin UI and View scope beans are not always destroyed correctly added
Updated by Andreas Kohlbecker over 6 years ago
- Related to bug #7046: replace open session per view pattern by DTO strategy added
Updated by Andreas Kohlbecker over 6 years ago
- Related to bug #7036: correctly release vaadin view resources when the browser windows has been closed added