[release/2.1] Fixes driver behavior of sending Attention signal for successful Bulk Copy operation

[cheenamalhotra]

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

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

[danmoseley]

@cheenamalhotra we are minimizing changes to 2.1 so we have a high bar. Eg support ticket with major customer or widespread major customer impact. Does this fit?

[cheenamalhotra]

Hi @danmosemsft

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.

cc @saurabh500

[danmoseley]

OK thanks @cheenamalhotra I pasted that above and we'll talk about it probably on Thurs.

[danmoseley]

Closing for now as mentioned in the 3.1 PR.