Transaction._free drops more references, and Transaction.abort() is a bit safer #84
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Specifically, free the manager and synchronizers, plus a few other dictionaries that could be arbitrary size and some of which could contain arbitrary data.
And
abort()
always invokes_free()
even in the case of exceptions.commit()
still doesn't so that the synchronizers are available for the expected abort().But take care about when and how abort frees its manager: not only does this preserve backwards compatibility, but it lets it be safe to abort a transaction object more than once. A happy side-effect of only freeing the manager there is that synchronizers can access
data they set in
afterCompletion()
.Previously, this code would raise
ValueError
; it now does nothing on the second call toabort
:If a synchronizer raised an exception in
beforeCompletion
, you'd be left with a transaction manager in a bad state and a difficult to clean up situation. Previously, the transaction would never be freed, so this final assertion held and resources joined to the transaction would not actually be aborted:Now the resources are properly aborted and the transaction manager can start a new transaction (assuming the bad synchronizer can be fixed, of course).
From discussion in #82