openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Struberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OPENJPA-2405) EntityManager.merge does not work for entity that is managed by another EntityManager
Date Fri, 28 Jun 2013 09:25:19 GMT

    [ 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

Mime
View raw message