Optimistic Transactions / Queued Operations Problems

[andyjefferson]

The current technique used to queue operations in optimistic transactions is flawed: it queues operations per collection and does not honour the order of operations between different collections. If I have an optimistic transaction which does the following:

(given: two objects with collection properties, one object of element type)

objectA.collection.add(element) objectA.collection.remove(element) objectB.collection.add(element) objectB.collection.remove(element) objectA.collection.add(element)

The outcome after commit depends on the order in which the collections are processed.

A: add(element), remove(element), add(element) B: add(element), remove(element)

With relationship management, element.owner would now be null; if B is processed first, it would be A. If everything was processed in order, it would be A (i.e. A would be correct / expected).

Originally raised on old DN forum.

[andyjefferson]

DataNucleus has had a single "OperationQueue" since v4.0 and so part of this was enabled back then.

In terms of RDBMS, CollectionMapping, MapMapping and ArrayMapping all have calls to ExecutionContext.flushOperationsForBackingStore and these would need removing, and instead to go through the queued operations one by one (as well as processing inserts/updates/deletes in the same way via the OperationQueue).

Clearly though we need testcase(s) that demonstrate the need for this before anything happens