为什么SqlAzureExecutionStrategy无法处理错误:19-物理连接不可用 [英] Why does SqlAzureExecutionStrategy not handle error: 19 - Physical connection is not usable

问题描述

完全例外:

System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. ---> System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: Session Provider, error: 19 - Physical connection is not usable)

为什么这不是由SqlAzureExecutionStrategy处理?尤其是因为这是在VIP交换期间发生的.

Why isn't this handled by the SqlAzureExecutionStrategy? Especially because this happens during VIP swaps.

编写一个自己的DbExecutionStrategy来处理这个问题是个好主意，还是我错过了什么?

Is it a good idea to write an own DbExecutionStrategy that handles this one, or am I missing something?

推荐答案

从探查器跟踪中，我们观察到使用了相同的连接 为每个查询数据库查询.这是设计使然并已讨论 早期，即当开发人员明确打开连接时 告诉EF不要为每个命令打开/重新打开连接.

From the profiler trace we observe that the same connection is used for each query database query. This is by design and as discussed early, i.e. when a connection is explicitly opened by the developer it tells EF not to open/reopen a connection for each command.

当然，这听起来不像一般性声明.什么探查器跟踪?为什么假设开发人员明确打开并处理了EF的连接?我在原始问题中看不到任何类似的东西(并且这在EF中并不常见).

Well this certainly does not sound like general statement. What profiler trace? Why suppose connection explicitly opened by the developer and handled to the EF? I dont see anything like this in original question (and it is not common practice with EF).

因此问题仍未得到解答:为什么SqlAzureExecutionStrategy不能处理此问题?编写一个自己的DbExecutionStrategy来处理这个问题是一个好主意吗?

So the questions remain unanswered: Why isn't this handled by the SqlAzureExecutionStrategy? Is it a good idea to write an own DbExecutionStrategy that handles this one?

由于我有时会在我的Azure服务中看到此错误，因此我决定对其进行测试.这是我的策略:

Since I can see this error in my Azure service from time to time, I decided to test it. Here is my strategy:

public class ExtendedSqlAzureExecutionStrategy : SqlAzureExecutionStrategy
    {
        public ExtendedSqlAzureExecutionStrategy(int maxRetryCount, TimeSpan maxDelay) : base(maxRetryCount, maxDelay) 
        { }

        protected override bool ShouldRetryOn(Exception exception)
        {
            return base.ShouldRetryOn(exception) || IsPhysicalConnectionNotUsableSqlException(exception);
        }

        private bool IsPhysicalConnectionNotUsableSqlException(Exception ex)
        {
            var sqlException = ex as SqlException;
            if (sqlException != null)
            {
                // Enumerate through all errors found in the exception.
                foreach (SqlError err in sqlException.Errors)
                {
                    if (err.Number == 19)
                    {
                        return true;
                    }                    
                }
            }

            return false;
        }
    }

编辑

好，所以经过一段时间记录后，我可以说该策略基于

Ok, so after some time and logging I can tell that the strategy based on

if (err.Number == 19)

错误.此错误的实际SqlException对象具有ErrorCode = -2146232060和Number = -1-我找不到关于这些的任何文档，因此我决定不基于它们制定策略.现在，我正在尝试琐碎检查:

is wrong. Actual SqlException object for this error has ErrorCode = -2146232060 and Number = -1 - I could not find any documentation for those, so I decided not to base strategy on them. For now I am trying trivial check:

public class ExtendedSqlAzureExecutionStrategy : SqlAzureExecutionStrategy
    {
        public ExtendedSqlAzureExecutionStrategy(int maxRetryCount, TimeSpan maxDelay) : base(maxRetryCount, maxDelay) 
        { }

        protected override bool ShouldRetryOn(Exception exception)
        {
            return base.ShouldRetryOn(exception) || IsPhysicalConnectionNotUsableSqlException(exception);
        }

        private bool IsPhysicalConnectionNotUsableSqlException(Exception ex)
        {
            var sqlException = ex as SqlException;
            if (sqlException != null)
            {
                return sqlException.Message.Contains("Physical connection is not usable");
            }

            return false;
        }
    }

它有效.根本没有任何Physical connection is not usable错误，也没有RetryLimitExceededException，因此该错误实际上是暂时性的(可以通过重试解决)，因此我认为应将其包含在SqlAzureExecutionStrategy中

It works. No more Physical connection is not usable errors at all, and no RetryLimitExceededException, so this error is in fact transient (solvable by retry), so I think it should be included in SqlAzureExecutionStrategy.

这篇关于为什么SqlAzureExecutionStrategy无法处理错误:19-物理连接不可用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！