"Transaction.abort" should abort the resources in the inverse order then "commit" commits the resources about transaction

[tseaver]

For reference, the place where the reverse sort would be applied is this line.

[d-maurer]

Despite the title, I am not sure about the best abort order. My case has demonstrated that the abort order can be important - however, it does not clearly indicate which abort order is the best.

I will analyse my case in more detail in the next few days and will report about the results.

[d-maurer]

The abort order I have proposed in the title would not help in my case. In this case, the commit order is QueueTM resources followed by the ZODB connection. This means, that in this special case, using the commit order for abort as well would be the right choice (still not sure about other cases).

[jimfulton]

Having storage-level machinery depend on persistent object state is a bad idea.

I don't want to make the transaction machinery more complex to support a brittle design.

[tseaver]

@jimfulton FWIW, how does that explain the use of dm.sortKey() during commit()? I would find it credible that abort() should use the same ordering.

[jimfulton]

The sort key is needed to avoid deadlocks. Abort has no such issue.

(The sort-key is potentially useful for ordering a faux-transactional DM after regular ones, but I regret that model in the first place. :-) )