处理由于服务器故障转移而失败的数据库查询
在具有 SQL Server 故障转移群集或镜像的环境中，您更喜欢如何处理错误？似乎有两种选择：
- 使整个当前客户端请求失败，让用户重试
- 捕获 DAL 中的错误，然后在那里重试
每种方法都有其优点和缺点。我合作过的大多数商店都遵循#1，但其中许多也不遵循严格的交易界限，在我看来，一旦发生故障，他们就会陷入困境。即便如此，我还是很难说服他们进入#2，这也应该会带来更好的用户体验（一个问题是故障转移发生时可能会出现较长的延迟）。
任何一种方式或另一种方式的争论将不胜感激。如果您使用第二种方法，您是否有一个有助于简化实现的标准包装器？无论哪种方式，如何构建代码以避免诸如与失败的命令中缺乏幂等性相关的问题？
In an environment with a SQL Server failover cluster or mirror, how do you prefer to handle errors? It seems like there are two options:
- Fail the entire current client request, and let the user retry
- Catch the error in your DAL, and retry there
Each approach has its pros and cons. Most shops I've worked with do #1, but many of them also don't follow strict transactional boundaries, and seem to me to be leaving themselves open for trouble in the event of failure. Even so, I'm having trouble talking them into #2, which should also result in a better user experience (one catch is the potentially long delay while the failover happens).
Any arguments one way or the other would be appreciated. If you use the second approach, do you have a standard wrapper that helps simplify implementation? Either way, how do you structure your code to avoid issues such as those related to the lack of idempotency in the command that failed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
第二个可能是无限循环。如果与网络相关，或者本地电脑需要重新启动，或者其他什么情况怎么办？
当然，第一点对用户来说很烦人。
如果您只允许通过网站进行访问，那么您永远不会看到该错误，除非在呼叫中发生故障转移。对我们来说，这是不可能的，我们已经在最终用户没有意识到的情况下进行了故障转移。
在现实生活中，您的 Web 服务器上可能没有干净的 DAL。您可能有一个 Excel 工作表连接（大多数财务数据）或 WinForms，其中连接保持打开状态，因此您只有一个选项。
无论如何，故障转移应该只需要几秒钟。如果数据库恢复花费的时间超过这个时间，那么无论如何您都会遇到更大的问题。如果这种情况发生得足够频繁，以至于不得不考虑如何处理它，那么……
总之，这种情况很少发生，您想知道，并且第 1 种情况会更好。恕我直言。
Number 2 could be an infinite loop. What if it's network related, or the local PC needs rebooted, or whatever?
Number 1 is annoying to users, of course.
If you only allow access via a web site, then you'll never see the error anyway unless the failover happens mid-call. For us, this is unlikely and we have failed over without end users realising.
In real life you may not have nice clean DAL on a web server. You may have an Excel sheet connecting (most financials) or WinForms where the connection is kept open, so you only have the one option.
Fail over should only take a few seconds anyway. If the DB recovery takes more than that, you have bigger issues anyway. And if it happens often enough to have to think about handling it, well...
In summary, it will happen that rarely that you want to know and number 1 would be better. IMHO.