2

因此,在发布到Azure应用服务网站的WebAPI控制器中有以下普通代码。这是给我的Open调用传输错误异常时使用Sql Azure在Azure应用程序服务上进行TransactionScope

using (var tx = new TransactionScope()) 
{ 
    var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["OrganizationManagement"].ConnectionString); 
    connection.Open(); 
    return Enumerable.Empty<TimeSessionDTO>(); 
} 

100%:

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

我已经使用从瞬态故障使用指数重试政策处理EL块ReliablSqlConnection尝试,而且我最终会因此而导致事务超时。

如果我删除了周围的TransactionScope,它可以工作,并且不会引发异常。

如果我在本地机器上运行相同的代码,并且连接字符串仍然指向SQL Azure数据库,则它对TransactionScope可以正常工作。

可能会发生什么,我无法在Azure网站中的事务内部打开数据库连接?

更新:我还应该注意,在TransactionScope中使用实体框架DbContext工作正常。由于某种原因,它只是简单地阻塞了ADO.NET。

仅供参考我也在Azure上的新MVC应用程序上尝试过,结果相同。我只是不明白:)

+0

实际上这不再与实体框架一起工作。我真的不明白:) – Gerald

回答

1

哇,所以这个问题似乎已经与连接字符串。当我第一次部署数据库时,我让数据库项目从服务器/数据库/用户信息构建连接字符串,我稍后将其添加到WebAPI项目的Web.config文件中。然后,当我部署了WebAPI项目时,我想它会在发布配置文件中保存该连接字符串。

事实证明,连接字符串使用的格式和选择方式与在Azure门户中查看连接字符串时提供的格式和选项不同。我已经在Web.config文件中更改了它,但似乎发布配置文件中的内容会覆盖Web.config中的内容,所以更改从未在服务器上生效。

我想这解释了为什么当我在本地运行时它工作,但我不知道为什么它只在事务中失败。