[
https://issues.apache.org/jira/browse/OPENJPA-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695338#comment-13695338
]
Mark Struberg commented on OPENJPA-2405:
----------------------------------------
Well, imo it's an OpenJPA bug in any case. If we simply ignore managed entities
in em.merge() than we must not insert the children into the database twice
neither.
Regarding 3.2.8: In this paragraph 'instance' clearly does not mean 'entity
identity' but 'java identity' as indicated by the sentence: "The behavior is
undefined if the same Java instance is made managed in more than one
persistence context."
In any case I'm not sure if 'fixing' this would help you, Arne.
I guess it's all about the entitymanager-per-request pattern and a premature
redirect().
In this case it might happen that finishing the first request (the one with the
redirect) takes longer to end than the new request to hit the server (in a
parallel thread now).
In this case the flush() on the first request might change your records in the
db and also update the @Version in those Entities. So even if you would get the
entity merged into another EM in the 2nd request it would contain the old
@Version and you will blow up at the end of the 2nd request with an
OptimisticLockException. Doesn't sound good neither, right? :)
There are now 2 ways to solve this issue in your application (even without
changing OpenJPA)
1.) Use a Servlet Filter to synchronize on your Session for those requests. Be
careful as this might cause unnecessary locks ...
2.) explicitly invoke em.flush() and em.close() before you do the redirect. And
hope that your @Transactional Interceptor can deal with it :) For JSF apps we
might be able to register a hook for the redirect in the FacesContext. Need to
check...
This might btw also work a bit different depending if you use synchronized or
unsynchronized EM (see JTA-2.1 and em.joinTransaction()).
Summary: multi-page 'wizard' style pages without DTOs suck at this time. We
need this new pattern we've talked about last week where we use
em.joinTransaction() to explicitly store the entity in the 'save' action on the
last page - without having the em.merge() operations automagically prematurely
store all changes into the database on the intermediate pages. Still thinking
about how this can be done best with OpenJPA
> EntityManager.merge does not work for entity that is managed by another
> EntityManager
> -------------------------------------------------------------------------------------
>
> Key: OPENJPA-2405
> URL: https://issues.apache.org/jira/browse/OPENJPA-2405
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 2.2.3
> Reporter: Arne Limburg
> Attachments: OPENJPA-2405.patch
>
>
> EntityManager.merge does not work for entity that is managed by another
> EntityManager. Instead of updating that entity OpenJPA tries to persist the
> entity a second time
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
