| Help on clone method [message #873076] |
Thu, 17 May 2012 09:15  |
Eclipse User |
|
|
|
I'm working with an EclipseLink 2 application that is exhibiting a problem with duplicated records. I think I have tracked the problem down to a clone method in one of our Entities. This clone() clears the id itself, rather than having the calling routine do it. I suspect that EclipseLink is cloning an object for a new unit of work and a duplicate is being created at that time. Since the id has been cleared, the work object gets saved as a new persistent object. Unfortunately, my knowledge of EclipseLink is not deep enough to back up this assumption. Could someone more knowledgeable tell me whether a clone method like this would cause the problem I'm seeing, and whether the quick fix of taking out the id clearing (and compensating in client code) is all I need?
@Override
public SomeEntity clone() throws CloneNotSupportedException {
SomeEntity clone = (SomeEntity) super.clone();
clone.setId(null);
clone.setCreatedDateTime(null);
clone.setCreatedUser(null);
return clone;
}
Finally, how could I go about testing this scenario?
|
|
|
| Re: Help on clone method [message #873245 is a reply to message #873076] |
Thu, 17 May 2012 15:48  |
| Eclipse User |
|
|
|
Simplest test is to print off the stack when it gets called - (new RuntimeException()).printStackTrace(), or use a breakpoint in a debugger.
EclipseLink will use its own methods to create backups and working/managed instances, which involves creating a new instance and populating it with the required attributes. This is configurable though through a copy policy described here:
http://wiki.eclipse.org/EclipseLink/Features/Core#Clone.2FCopy_Policy
and http://wiki.eclipse.org/Configuring_a_Descriptor_%28ELUG%29#Configuring_Copy_Policy
with the default being the InstantiationCopyPolicy. If JPA method access and weaving is used, the default is a PersistenceEntityCopyPolicy which uses a _persistence_shallow_clone() method.
I've found duplicates can occur when objects are not correctly persisted/merged, but that probably doesn't help track down how to find them. Adding debugging to your entities themselves and turning EcliseLink logging to finest so you can see where they might get inserted could help. I believe EclipseLink will print off the entity as persist/merge gets called on it at the finest log level.
Best Regards,
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.25932 seconds
Home