-
Notifications
You must be signed in to change notification settings - Fork 293
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
BUG: SqlDelegatedTransaction hides promoteException #1163
Comments
Hi @ionmincu Thanks for sharing details. I'm working on a PR to address this. |
@cheenamalhotra any updates on this? |
@cheenamalhotra any updates on this? Any ideea on how can I get better insights into this issue? |
@cheenamalhotra Aparently we are using |
Thanks, that would be helpful. |
@cheenamalhotra using https://www.nuget.org/packages/ErikEJ.EntityFramework.SqlServer/6.4.0 package I was unable to reproduce the bug in |
I understand this can be hard to reproduce. If you know of the test case that fails for you, you could capture logs and try to force the situation. That can help identify reproducible scenario. If it's related to concurrency, I'd recommend increasing load to make it fail more often. |
I tried running our integration tests countless times on smaller vms even and it does not seem to reproduce. I will try to repro on MDS with even smaller VMs and reduce cpu time to sql server. Also regarding SQL Server we have seen this on SQL Azure and SQL Sever 2019 on linux Docker. |
@cheenamalhotra I could not repro this on DECLARE @result int;
EXEC @result = sp_getapplock @Resource, @LockMode, @LockOwner, @LockTimeout;
SELECT @result
-- values
@LockMode = Exclusive
@LockOwner = Transaction When running with 0.1 CPU we get quite a few operation timeouts, but no |
@cheenamalhotra after we switched to
|
I know it was fixed in |
Description
Sometimes on our servers we see the exception below. I think this is a problem because it hides the underlying promoteException
Excepton message:
Issue #784 seems to present the same stacktrace (second one) .
This mentions #543 which seems to be the culprid because they introduced a new
if
statement and checks the status hereSource: https://github.com/dotnet/SqlClient/pull/543/files#diff-318a0b3769dd34240f6758ac2efc7fc599875e28230753d10d438f6a1c797fbfR211
Stacktrace:
We found the same stack trace under a Windows environment as well
Configuration
Regression?
Related
if
where a getter is called onTransaction.TransactionInformation.Status
The text was updated successfully, but these errors were encountered: