-
Notifications
You must be signed in to change notification settings - Fork 299
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
Different error handling between Microsoft.Data.SqlClient and System.Data.SqlClient #784
Comments
@cjindustries If you take a closer look, you'll notice the stacktraces are little different as it fails in Microsoft.Data.SqlClient during status check before trying to promote transaction:
whereas in System.Data.SqlClient, it actually went to Execute Transaction Promotion and then failed:
This difference is due to recent changes we made to handle delegated transactions better in PR #543 which is actually keeping the driver safe and fixes some critical issues by validating transaction state and not making unwanted server calls. I don't see it as a bug as this is a new library and is in active development cycle, now open source. We try our best to be backwards compatible, but such changes are expected as we fix critical issues and move forward. |
@cheenamalhotra thanks for the reponse, and understood; I just wanted to flag it for review. I must say that the response of MDS in this case is less useful in terms of information that SDS, since SDS gives me an idea of the root cause. |
Describe the bug
Some Background
We're porting our solution (.Net 4.7.2) over to use Microsoft.Data.SqlClient from System.Data.SqlClient. There are some components we're still using (like EF) that don't support MDS so we're looking at how the two clients can co-exist.
In the past we've tried to avoid requiring distributed transactions where possible but there's a chance we'll now have some if the two clients are used in the same transaction. To track this, our TransactionScopeFactory class in use throughout the solution has had some optional logging added which is sent to Serilog.
During testing of an ASP.Net controller, we found that we were unexpectedly getting escalating transactions. The code itself (which I can't send over) was accessing data in the same table (in two serial queries) and then an AJAX callback was doing similar. Not ideal, and under some load was causing issues for MDS.
The interesting thing however is that SDS and MDS perform differently. SDS was working fine whereas MDS was encountering issues, and these would vary depending on what we did in the TransactionCompleted event handler we added in the TransactionScopeFactory class.
I can't reproduce the exact issue but during the course of my investigations a test I've written shows that SDS and MDS return different errors in the same error situations, and I wanted to flag this up. I feel they're related to my issue but not the same.
The Issue
SDS and MDS return different errors in the same error situations. Is this correct/acceptable? I just wanted to flag this up since it may make porting difficult.
In general, where for SDS I might get "The transaction has aborted" as part of an aggregate exception for MDS I get "The operation is not valid for the state of the transaction". Should they not act in the same way?
Here are two examples of the same test for SDS and then MDS:
To reproduce
I've attached my test solution and an example of the output.
The test exercises each client with different combinations of settings and logging.
The output from the tests are in two files - SqlClientTest_Log.txt which is a log of the tests and SqlClientTest_Results.csv.txt which is a CSV you can filter in Excel.
Expected behavior
I expect the clients to fail but I think I expected them to fail with the same error. I may be wrong.
Further technical details
Microsoft.Data.SqlClient version: 2.0.1
.NET target: Framework 4.7.2
SQL Server version: SQL Server 2019 Developer
Operating system: Windows 10
SqlClientTest_Log.txt
SqlClientTest_Results.csv.txt
SqlClientTest_Results.zip
The text was updated successfully, but these errors were encountered: