-
Notifications
You must be signed in to change notification settings - Fork 934
Fix transaction leak #2310
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
Fix transaction leak #2310
Conversation
@@ -370,6 +370,7 @@ protected virtual void Dispose(bool isDisposing) | |||
// don't dispose of multiple times. | |||
return; | |||
} | |||
_isAlreadyDisposed = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change kept from #2144: flagging it at the end of this method instead of as soon as possible causes the method to be vulnerable to an endless loop, in case a Dispose
is performed inside AfterTransaction
, called later by this method.
This change was required by #2144 since it was calling Dispose
in AfterTransaction
. This PR here does not do it and so does not actually need that change, but still it is safer to have it.
f96692a
to
e0f606a
Compare
02ce4bb
to
21cf2bb
Compare
21cf2bb
to
b779aee
Compare
This comment has been minimized.
This comment has been minimized.
b779aee
to
04afb3e
Compare
To be squashed
04afb3e
to
443b462
Compare
Rebased for checking the generator update was not requiring a regen for this PR. |
I did a merge as 2 commits have better representation of the work done. |
Fixes #2144
Instead of disposing
ConnectionManager._transaction
inAfterTransaction
as proposed in #2144, this obsoletesConnectionManager.Transaction
in favor of a newConnectionManager.CurrentTransaction
property which does not create a transaction when none are already created, but yieldsnull
.So now any existing transaction should be the result of a call to
BeginTransaction
, and its disposal is always a responsibility of the caller.