New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DB.undo() leaks MVCC storages #268
Comments
This problem is made worse by the fact that there's a reference cycle involved, so the connections won't get cleaned up until the GC runs at some arbitrary point in the future. The reference cycle was completely non-intuitive. The active transaction points to the
EDIT: As pointed out in zopefoundation/transaction#82, the transaction does drop the IDataManager objects it has when a transaction is committed, so there must be another cycle somewhere. |
The |
I'll try to manually break this cycle and then go hunting again. Failure to close the storage was easy to diagnose and correct, though. |
I see this in the relstorage tests. That means the underlying database connections leak.
Here's where a storage is allocated by calling
new_instance()
:The
TransactionalUndo
object never closes the new storage.RelStorage could potentially work around this (e.g., implement a 'undo_instance' method that returns a special storage wrapper that closes itself in
tpc_finish
andtpc_abort
), but it seems like the more general solution would be forTransactionalUndo
to close the storage it opened in its implementation of those methods.The text was updated successfully, but these errors were encountered: