This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
[release/3.1] Fix driver behavior of sending Attention signal for successful Bulk Copy operation #42617
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.
Port of: dotnet/runtime#61 and dotnet/SqlClient#308
Summary
Currently when performing Bulk Copy operations with SqlClient driver, on successful completion, an Attention Signal is sent to SQL Server which is not correct behavior and should not happen.
Customer Impact
Reported by a .NET Framework customer.
Customers wouldn't notice these attention signals being sent and the transactions would only get impacted if the Abort bit is checked during transaction prepare/commit time. This case would be easily hit with HK tables when the transaction inserts a large number of rows, hence causing all the LCs to be filled up and LC flush IO to fall behind LCs being requested for log serialization at transaction prepare time.
I would vote for getting the fix in 2.1 as this would result in unsuccessful Bulk Copy transactions for customers even though no error has occurred on their end as this was incorrect behavior by design.
Also to note, it's very likely to occur if customers are using Hekaton/memory-optimized tables. Log serialization in HK is done right at the end during the Hekaton transaction “preparation” phase, prior to commit. This implies that all required log records are generated/serialized into Log Cache at transaction prepare time. As a result, if there are a large number of log records to serialize, there could be a situation where Log Cache get filled up and need to be flushed while more log records are waiting to be serialized into Cache. However, if LC flush IO cannot keep up with the rate of LCs being requested for remaining log records, SQLServerLogMgr::WaitFlushOldestLC() is called, which will essentially wait for a free Log Cache. This function when executed also checks whether the task has an Abort bit set (which is set when the server receives the Attention packet), which ends up aborting the transaction commit itself.
Regression?
No. The behavior is the original design ported from .NET Framework.
Testing
When performing tests, the transactions would always commit successfully, hence this attention signal was not noticed. A special test case will be investigated and designed using HK tables in dotnet/sqlclient test lab to cover this scenario. Since all new changes will be made in dotnet/sqlclient repository, we'll be adding new tests there in future.
Risk
Low: The fix is to not send attention signal when performing cleanups post Bulk Copy in successful scenarios.
cc: @danmosemsft @David-Engel @saurabh500