站点更新，测试正常，部署后，再次正常，一旦用户负载增加，失败？
我们使用 ASP.NET MVC 和 LINQ to SQL。我们添加了一些功能，并在我们的 QA 盒子上对它们进行了完美测试。我们使用的是 Windows Server 2003 和 SQL Server 2005。因此，当我们将更改推送到 Live Web 服务器时，我们还使用 Red Gate SQL Compare 将新的数据库更改推送到 LIVE 数据库。我们几个人又测试了一遍，没有问题。睡觉时间到了。
早上到了，用户开始使用该应用程序，然后轰隆隆地响了起来。我们不知道为什么会发生这种情况，因为我们没有做任何以前没有做过的新类型的代码事情。然而，我们确实注意到，在 SQL 比较同步期间，两个数据库之间所有外键的名称都不同，而不是表中的 ID（FK_AssetAsset_A0EB67 到 FK_AssetAsset_B67EF8）（例如，不记得期间尾随混合字符的确切数量） SQL Compare），我们不确定为什么，但这是这个问题中的另一个变量。
奇怪的是，一旦这一切都被推出，我们就可以在 QA 上复制错误，但不是在所有内容都被推送到 LIVE 之前。
QA 和 LIVE 数据库位于同一 SQL Server 上，但应用程序位于 Windows Server 2003 的不同实例上。
生成的错误：
索引超出了数组范围。
阅读器关闭时调用 FieldCount 的尝试无效。
服务器无法恢复事务。
已经有一个打开的 DataReader 与此命令关联，必须先将其关闭。
向服务器发送请求时发生传输级错误。
从服务器接收结果时发生传输级错误。
阅读器关闭时调用 Read 的尝试无效。
阅读器关闭时调用元数据的尝试无效。
计数必须为正数，并且计数必须引用字符串/数组/集合中的位置。参数名称：count
ExecuteReader 需要一个打开且可用的连接。连接的当前状态为正在连接。
有人知道到底发生了什么吗？
编辑：由于我们能够在 QA 上突然复制错误，这可能不是用户负载问题......不用说，我们都觉得这里真的很糟糕。
We are using ASP.NET MVC with LINQ to SQL. We added some features and tested them all to perfection on our QA box. We are using Windows Server 2003 and SQL Server 2005. So when we pushed out changes to the Live web server we also used Red Gate SQL Compare to push new database changes to the LIVE database. We tested again between the few of us, no problems. Time for bed.
The morning comes and users are starting to hit the app, and BOOM. We have no idea why this would happen as we have not been doing any new types of code things that we were not doing before. However we did notice that during the SQL Compare sync the names of all the foreign keys were different between the two databases, not the IDs in the tables, FK_AssetAsset_A0EB67 to FK_AssetAsset_B67EF8 (for example, don't remember the exact number of trailing mixed characters during the SQL Compare), we are not sure why but that is another variable in this problem.
Strangely once this was all pushed out we could then replicate the errors on QA, but not before everything was pushed to LIVE.
QA and LIVE databases are on the same SQL Server, but the apps are on different instances of Windows Server 2003.
Errors generated:
Index was outside the bounds of the array.
Invalid attempt to call FieldCount when reader is closed.
Server failed to resume the transaction.
There is already an open DataReader associated with this Command which must be closed first.
A transport-level error has occurred when sending the request to the server.
A transport-level error has occurred when receiving results from the server.
Invalid attempt to call Read when reader is closed.
Invalid attempt to call MetaData when reader is closed.
Count must be positive and count must refer to a location within the string/array/collection. Parameter name: count
ExecuteReader requires an open and available Connection. The connection's current state is connecting.
Any one have any idea what the heck could have happened?
EDIT: Since we were able to replicate the errors all of a sudden on QA, it might not be a user load issue... Needless to say we all feel really screwed here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
并发总是会带来意想不到的错误。我建议您检查可以在请求之间共享的对象（例如静态成员和单例）并重构您的代码，以便尽可能少地共享。
就具体情况而言，对于错误“已经有一个与此命令关联的打开的 DataReader 必须首先关闭”，您可能需要尝试将 MultipleActiveResultSets=True 添加到连接字符串中。
Concurrency always brings bugs out of the woodwork. I'd recommend you check for objects that could be shared among requests (such as static members and singletons) and refactor your code so that as little as possible is shared.
As far as specifics go, for the error "There is already an open DataReader associated with this Command which must be closed first," you may want to try adding MultipleActiveResultSets=True to your connection strings.
听起来您正在稍微跨越流并尝试跨请求共享 DataContext。我的建议是连接一个依赖注入框架，为每个请求创建一个新的依赖实例。
我使用 Castle 的 IoC 并将其连接到控制器工厂，以便当它看到对存储库的依赖性时，它会为每个请求创建该存储库的新实例。如果您选择这条路线，请告诉我，我可以为您提供更多资源。
It sounds like you're crossing the streams a bit and trying to share DataContexts across requests. My suggestion would be to wire in a dependancy injection framework that creates a new instance of the dependancy for each request.
I use Castle's IoC and wire it into the controller factory so that when it sees a dependancy on a repository it creates a new instance of that repository for each request. If you go this route let me know and I can shoot you a few more resources.