search

zopefoundation / transaction

Generic transaction implementation for Python.
Other
70 stars 31 forks source link

"Transaction.abort" should abort the resources in the inverse order then "commit" commits the resources #6

Closed d-maurer closed 9 years ago

d-maurer commented 9 years ago

The order in which resources are committed during a commit can be important. For this reason, this order can be influenced by defining a method sortKey on the resources. For abort, the resources are aborted in registration order - independent of sortKey.

However, the order in which resources are aborted can be important as well. In my case, a Plone portal should be created. During the operation, a ZODB connection and various collective.indexing.transactions.QueueTM objects register with the transaction (in this order). An error during the portal creation causes a transaction.abort() which fails, because the connection abort ghostifies the portal's component registry and the collective.indexing.transactions.QueueTM abort depends on it.

It would be good to have control not only over the commit order but also over the abort order of resources. I assume that aborting resources in the inverse order of committing them would most likely give acceptable results.

tseaver commented 9 years ago

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

d-maurer commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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. :-) )