-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Allow managing transactions via SQL commands in the update pipeline #27532
Comments
This is unfortunately problematic: if we append COMMIT to the end, we have no opportunity to roll back if a concurrency exception occurs. Some thoughts:
|
This depends on: Also, make sure that even after #10433, this is still compatible with SQL Server, i.e. that XACT_ABORT gives us the transaction abort behavior we need (in any case, this needs to be provider-opt-in since providers may not support the right abort behavior, or need special settings like XACT_ABORT). Leaving in 7.0 for now, but deferring for later in the milestone. |
SaveChanges implicitly starts a transaction around all changes (except where one isn't needed, see #27439). This is done by calling the standard ADO.NET APIs, DbConnection.BeginTransaction and DbTransaction.Commit. Unfortunately, each of these APIs does a roundtrip, so a typical SaveChanges involves 3 roundtrips instead of just one. Some benchmarking:
Benchmark code
We could get around this by managing transactions manually: prepend BEGIN to the first batch, and append COMMIT to the last batch.
Originally discussed in #4351
The text was updated successfully, but these errors were encountered: