Question

最近，我们遇到了一个问题，一个过程通常需要几秒钟才能执行，一天要花费一个小时，然后第二天要花费将近9个小时。我正在调查的是一个单独的问题，但是我想在这里讨论的问题是，通过Entity Framework调用有问题的查询的超时时间为600秒，并且当进程开始长时间运行时，没有超时异常触发。

在长时间运行的每个流程实例中，该流程最终都成功完成，没有错误生成。我们不会覆盖与DbContext相关的任何内容，因此默认超时30秒仍然适用。

我们通过评估SQL Server实例上的当前执行情况来验证查询是否仍在运行。我的第一个想法是查询已完成，但是该视图的实体类中带有实体键列的愚蠢行为导致它需要永远验证。该对象上只有1个Entity Key列，它是视图主表的PK。我们还确认该数据集未返回重复记录。因此，所有情况都表明，查询在整个过程中都在执行，并且没有生成超时异常。

有人在自己的环境中体验过EF吗？

我们使用EntityFramework 6.1.3和SQL Server Standard 2016 SP2 CU4。

代码示例：

EntitiesCommandTimeout = 600

if (ConfigurationManager.AppSettings.AllKeys.Contains("EntitiesCommandTimeout"))
{
    _entitiesCommandTimeout = Convert.ToInt32(ConfigurationManager.AppSettings["EntitiesCommandTimeout"].ToString());
}

...

using (var db = new myContext())
{
    db.Database.CommandTimeout = _entitiesCommandTimeout;
    List<vwMyView> myViewItems = db.myView.Where(v => v.myColumn == myVariable).ToList();                
}

更新2019-03-19： 我忘了提到，当我的一位开发人员通过Visual Studio在本地运行此过程，并且配置文件集与我们在Prod中设置的匹配时，就正确触发了超时异常。

实体框架超时未触发

0 个答案: