Convert ExecuteNonQueryAsync to use async context object #1692
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.
fixes #1682
This addresses the incorrect handling of cancellation token registrations in
SqlCommand
methodsExecuteNonQuery
andExecuteReader
, I didn't changeExecuteScalar
because it should be done in a separate PR and it's justExecuteReader
wearing a fake nose a glasses, people should useExexuteReader
Background information: There are a number of async api calls on
SqlDataReader
which have been changed to avoid the use of language provided lambda closures and instead use explicit context objects. This process makes the code more complicated because it splits apart the code into multiple functions so that instance delegate allocations can be avoided. This pattern is no longer needed if we use language provided static lambdas and the code can be much cleaner and better contained. This PR converts the ExecuteNonQuery function to use this explicity context pattern and uses static lambdas to doi t.This PR also changes all existing context objects to use an explicit type for the IDispoable so that we can avoid boxing the disposable. This change forces any existing context types which were declared like this:
AAsyncContext<TOwner,TResult>
to be split apart into two types,AAsyncContext<TOwner,TResult,TDisposable>
which has a strong disposable type and is used at call sites that know what the disposable is, mostly setup locations.AAsyncBaseContext<TOwner,TResult>
which is used in the async functions that don't need to know what the type of the disposable is so we can avoid duplicating functions likeInvokeAsync
The specific changes to fix the issue reported are
InternalExecuteNonQueryAsync
to use an explicity context object/cc @olegkv