Conceptually the diamond structure comes down to this:
- Batchtransfer handles stock changes (transfering a batch from one stock to the other).
- Productionorder uses a Batchtransfer to do its stock changes, so a Productionorder has one Batchtransfer.
- Each ProductionorderInputline is linked to one BatchtransferLine in the Batchtransfer.

The situation I have is that the Productionorder already is persisted, and I am going to add an inputline.

What you see in this line is that the Productionorder got a new Batchtransfer assigned, and that Batchtransfer has a new Batchtransferline.
On the second line you see that Productionorder also has a new ProductionorderInputline and it refers to the same Batchtransferline.
This is how it should be.

Productionorder was merged, so I have a new instance. Correct.
ProductionorderInputline was persisted, so it is the same instance, only got a number assigned. Correct.
Batchtransfer and BatchtransferLine were persisted, but they became new instances. Incorrect?

What is strange in the first place is that Batchtransfer and BatchtransferLine were persisted. There is no cascade persist anywhere, and the application never persists them.

The post before was a simplification of a complexer problem: originally all collections had CascadeType MERGE and PERSIST, and in that setup Eclipselink replaced my original Batchtransfer and BatchtransferLine. This did not occur with these cascade types off, but I did not understand the fact that the BT and BTL were still persisted.

By now I have found a (probably, it still in test) working solution: it turned out the MERGE was the cause of the behavior, so I removed that and added an explicit EM.merge() call on the PropertyChangeEvents of all entities.

Never the less, for my understanding, I would still like to know why BT and BTL are persisted if there is no cascade and no persist call.