I just saw something bigger for side effect in
discoverUnregisteredNewObjects than setUnregisteredExistingObjects.
Some of our use cases are randomly failing, and involve almost just
TopLink code.
Other use case involving delete do not delete.
New code that have nothing to do with discoverUnregisteredNewObjects
have been recently added to the method under revision 3676.
From the JavaDoc of method removePrivateOwnedObject that seems a good
candidate for explaining our delete use case failing. The code seems
to systematically remove object from privateOwnedObjects when ever
it’s private owned.
When an object (which is referenced) is removed from the
privateOwnedObjects Map, it is no longer considered for removal from
ChangeSets and the UnitOfWork identitymap.
public void iterateReferenceObjectForMapping(Object referenceObject,
DatabaseMapping mapping) {
super.iterateReferenceObjectForMapping(referenceObject, mapping);
if (mapping.isCandidateForPrivateOwnedRemoval()) {
removePrivateOwnedObject(mapping, referenceObject);
}
}
public boolean isCandidateForPrivateOwnedRemoval() {
return isPrivateOwned();
}
public void removePrivateOwnedObject(DatabaseMapping mapping, Object
privateOwnedObject) {
if (this.privateOwnedObjects != null) {
Set objectsForMapping = this.privateOwnedObjects.get(mapping);
if (objectsForMapping != null){
objectsForMapping.remove(privateOwnedObject);
if (objectsForMapping.isEmpty()) {
this.privateOwnedObjects.remove(mapping);
}
}
}
}
------------------------------------------------------------------------
*From:* eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Sebastien
Tardif
*Sent:* Wednesday, May 20, 2009 10:35 AM
*To:* Dev mailing list for Eclipse Persistence Services
*Subject:* RE: [eclipselink-dev] FYI:
uow.discoverUnregisteredNewObjectsisinefficient and with side effect
The method getBackkupClone() has two lines doing the cloning, maybe
you know for sure that these lines are never reached.
- return descriptor.getObjectBuilder().buildNewInstance();
- backupClone = descriptor.getObjectBuilder().buildNewInstance();
I still don’t like the side effect of the method
discoverUnregisteredNewObjects, could you provide one without side effect?
It’s kind of very useful to be able to find the list of
knownNewObjects and unregisteredExistingObjects.
------------------------------------------------------------------------
*From:* eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Gordon Yorke
*Sent:* Wednesday, May 20, 2009 10:26 AM
*To:* Dev mailing list for Eclipse Persistence Services
*Subject:* Re: [eclipselink-dev] FYI:
uow.discoverUnregisteredNewObjects isinefficient and with side effect
getBackupClone() does not actually build anything, it just looks for
the backupClone. It is just a validation step and has not been added
but moved out of the "normal" processing stream to improve performance
and efficiency.
--Gordon
Sebastien Tardif wrote:
FYI: uow.discoverUnregisteredNewObjects is inefficient and with side
effect
/**
* INTERNAL:
* Traverse the object to find references to objects not registered in
this unit of work.
*/
*public* *void* discoverUnregisteredNewObjects(Map clones, *final* Map
knownNewObjects, *final* Map unregisteredExistingObjects, Map
visitedObjects) {
The JavaDoc and signature seem to convey that the only change will be
to populate the Maps passed as parameters.
* *
*The inefficiency is that in revision 2794 this line has been added:*
* *
getBackupClone(object, getCurrentDescriptor());
We see that we ignore the return value, and we can guess that building
a clone is not the cheaper operation.
Method discoverUnregisteredNewObjects end-up modifying the UOW by
doing this: setUnregisteredExistingObjects(unregisteredExistingObjects);
The list of unregisteredExistingObjects will be returned anyway, so
that doesn’t seem to be the responsibility of
discoverUnregisteredNewObjects to apply some logic with the result.
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx <mailto:eclipselink-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev