MergeCloneAPI

You cannot register a serialized object into the unit of work directly, you must make use of the mergeClone API. In general there are 4 different mergeClones provided on the unit of work. forum:182154

shallowMergeClone()

Only merges direct attributes, and does not cascade or merge relationships. It should be used if you only edit the object's direct attributes on the client, or have marked all of the object's relationships as transient.

mergeClone()

Merges direct attributes and cascades private-owned relationships. It should be used if you only edit the object on the client and not its relationships, or have marked its idependent relationship as transient.

mergeCloneWithReferences()

Merge direct attributes, cascades private owned relationships, and merges the reference of its independent relationships, but does not cascade the merge to the independent relationships. It should be used if you edit the object and the targets of its relationships and have not marked any attributes as transient.

deepMergeClone()

Merges everything and cascades all relationships. You must be very careful using this API as it will cascade indefinitely or until it hits non-instantiated value-holders or cycles. You should not have any transient attributes in any of your related objects.

In general you should use deepMergeClone with caution, it will merge all related objects, and all their related objects. Most likely what is occuring is that your employee has a reference back to its organization which holds all of the employees, which sometimes may contain a change or not.

It is better to use mergeClone or shallowMergeClone to ensure you know what exactly is going to be merged and to avoid large object graph traversals. (emphasis added)

deepMergeClone() is a very useful feature of TopLink as it allows the application to not have to be concerned with what it changes on the client. The client can traverse any relationships of the objects that are serialized to it (provided the relationships were serialized) and make whatever changes to whatever objects it desires. It can then send the entire object graph back to the server which can does not have to be aware of what the client was doing and can just deepMergeClone everything back into a unit of work and commit the changes to the database.

Unfortunately the main benefit of deepMergeClone can also be its biggest issue when something goes wrong. DeepMergeClone traverses "everything" related to an object and merges "everything", for complex objects this can occasionally lead to the merging of changes that were not intended or desired by the client.

Examples can include:

• Transient attributes. These will be serialized as null so will be merged as null into the unit of work causing incorrect updates to null.
• Duplicate objects and loss of object identity. Since TopLink is not running on the client, it is possible for the client to violate object identity through retrieving two separately serialized objects from the server that contain relationships to the same object. If these two objects are then related and serialized back to the server and deepMergeClone'd, TopLink will be given two different versions of the same object, this object can be merged twice and one copy can overwrite the other copy. This may be what is occurring with the problem at the start of this thread.

There is another thread with a similar issue that also links to another thread that has a good description of each of the unit of work merge APIs. forum:218071

In general deepMergeClone() is a very useful feature, and if you are using it successfully definitely don't stop using it. But if you commonly experience problems, or performance issues, you may wish the consider one of the other merge APIs that give the application more control over what is and is not merged. forum:188069

See Also