Eclipselink JPA merge problemhttps://www.eclipse.org/forums/index.php/mv/msg/220672/696768/#msg_696768
I have been using Eclipselink 2.3 for a while in my standalone J2SE swing application, communicating with a remote MySQL database. Lately I have been experiencing some problems with merging entities. It seems that when calling merge, Eclipselink sometimes does not commit changes made to recently detached persisted entities. Here a log dump showing the exact problem

When creating a person entity in my swing application, it is persisted to the database first with an empty last name and firstname. This way it can have an id generated for the hashcode and equals to be consistent. After this, it is detached (tx after persist is closed) and added to a List which is shown in the GUI using the beans binding framework.

At that time, the user can edit the entity, and when he is done, save and merge the changes using the entityManager.merge opertation.

the entityManager.merge operation starts at the first line. There a person.toString() is dumped to the log, where one can clearly see that the name and the first name of the person entity are set by the user. 80% of the time the changed first name and last name are commited to the db.

By analyzing the eclipselink logging for a while now, I found that Eclipselink sometimes seems to refresh the entity from the database before performing an UPDATE, and sometimes not.

Can anybody here tell me when Eclipselink decides to check the values of an entity with the database when using the AUTO (=DEFERRED) change tracking setting ? I feel that this can be a possible reason to this issue. that Eclipselink thinks the entity in its cache is the latest version and takes the state of the entity as it was persisted at first to make the merge (so with empty last name and first name). Does anybody know a programmatical way to invalidate the cache here and force eclipselink to make a lookup before merging (so bypassing the change tracking algorithm)?

At this moment, I do not use any weaving for compatbility reasons (beans bindings seems to have trouble with it), so changeTracking should prolly stick with DEFERRED. I have heavily optimized the logic behind the merging, and only entities that are really dirty (edited by the user) are merged to the db. So invalidating the cache should not have too much of a performance impact here.

Thanks in advance
]]>Jeroen Peelaerts2011-07-14T19:36:33-00:00Re: Eclipselink JPA merge problemhttps://www.eclipse.org/forums/index.php/mv/msg/220672/698013/#msg_698013
Gordon Yorke2011-07-18T15:40:58-00:00Re: Eclipselink JPA merge problemhttps://www.eclipse.org/forums/index.php/mv/msg/220672/698133/#msg_698133
My domain model consists of an object graph in which the Person entity owns all the other entities (mostly one to many relationships). If something changes to any of those descendants, will the version still increment when merging the person? Or does this only happen when the person entity itself is updated?

Thanks for the tips alright..]]>Jeroen Peelaerts2011-07-18T20:50:30-00:00Re: Eclipselink JPA merge problemhttps://www.eclipse.org/forums/index.php/mv/msg/220672/701050/#msg_701050
When the find() returns an entity that has the same name, eclipselink will not go back to the db, as shown in the logging in my first post, and wil fail to save the updated entity. In this case, the entity seems to be available from the persistence context, despite being detached.

I'm wondering why sometimes these entities are up to date in the persistence context while the transaction in which they were persisted at first was committed and the related entitymanager closed. When I do a merge, they should not be available from the persistence context according to the jpa spec, or do I need to do a clear() after persisting every entity anyway?

For some reason eclipselink seems to be keeping track of the entity in its persistence context after it is persisted using persist(), even when the tx was committed and the entitymanager closed. Does anybody have a reasonable explanation for this?

Thanks.
]]>Jeroen Peelaerts2011-07-24T14:07:29-00:00(no subject)https://www.eclipse.org/forums/index.php/mv/msg/220672/701052/#msg_701052
When the find() returns an entity that has the same name, eclipselink will not go back to the db, as shown in the logging in my first post, and wil fail to save the updated entity. In this case, the entity seems to be available from the persistence context, despite being detached.

I'm wondering why sometimes these entities are up to date in the persistence context while the transaction in which they were persisted at first was committed and the related entitymanager closed. When I do a merge, they should not be available from the persistence context according to the jpa spec, or do I need to do a clear() after persisting every entity anyway?

For some reason eclipselink seems to be keeping track of the entity in its persistence context after it is persisted using persist(), even when the tx was committed and the entitymanager closed. Does anybody have a reasonable explanation for this?