You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation mentions that its likely that if the connection fails, this verifySucceeded one will fail also.
However it doesn't mention what happens in this case.
Lets say the connection drops during a transaction commit, and so the strategy retries and it invokes the verifySucceeded delegate to check if the transaction was indeed committed..
What if this check fails because the db connection is still failing? Does it end up retrying the operation anyway? Or will this surface the underying exception and prevent the execution strategy from retrying?
This is more of a design question checking for a possible bug. Is there a risk that when the connection originally drops during a commit - and the state of the transaction is not known to EF Core, that the retry strategy will invoke this verifySucceeded delegate - and we will check the transaction table and see that the transaction id is indeed not yet present - however the original transaction does indeed later succeed and the record will then appear afterwards? In other words can this verifySucceeded check happen "too quickly" resulting in a possible duplicate insert still? If the original transaction is very large - the commit phase might take a while no?
What if this check fails because the db connection is still failing? Does it end up retrying the operation anyway? Or will this surface the underying exception and prevent the execution strategy from retrying?
If verifySucceeded keeps throwing, then the exception will be surfaced (as usual when the retry limit is reached).
In other words can this verifySucceeded check happen "too quickly" resulting in a possible duplicate insert still? If the original transaction is very large - the commit phase might take a while no?
For that to happen the connection must fail before the commit finishes, but after it's too late to abort it. I'm not an expert on relational databases, but I'd think that period of time is orders of magnitude shorter than the time needed to establish a new connection.
Type of issue
Missing information
Description
As example is shown for using the
verifySucceeded
to check if the transaction was successful.The documentation mentions that its likely that if the connection fails, this verifySucceeded one will fail also.
However it doesn't mention what happens in this case.
Lets say the connection drops during a transaction commit, and so the strategy retries and it invokes the
verifySucceeded
delegate to check if the transaction was indeed committed..verifySucceeded
check happen "too quickly" resulting in a possible duplicate insert still? If the original transaction is very large - the commit phase might take a while no?Page URL
https://learn.microsoft.com/en-us/ef/core/miscellaneous/connection-resiliency#execution-strategies-and-transactions
Content source URL
https://github.com/dotnet/EntityFramework.Docs/blob/main/entity-framework/core/miscellaneous/connection-resiliency.md
Document Version Independent Id
29002343-fa42-2f49-3362-53592039b26d
Article author
@AndriySvyryd
The text was updated successfully, but these errors were encountered: