4

这是我假设的程序产生的事件序列......

  1. 打开与服务器的连接。
  2. 运行更新命令。
  3. 去做一些可能需要大量时间的事情。
  4. 运行另一个 UPDATE 以反转步骤 2 中的更改。
  5. 关闭连接。

但是哦，不！在第 3 步中，运行该程序的机器确实爆炸了。查询同一数据库的其他机器现在会认为爆炸的机器仍在工作并做某事。

我想做的就是在打开连接时，但在进行任何更改之前，告诉服务器无论出于何种原因，该连接是否应该关闭，以运行一些 SQL。这样，我可以确定如果出现问题，关闭更新将运行。

（为了抢占答案，我不是在寻找表/记录锁或事务。我不是在这里做资源声明。）

非常感谢，比尔PG。

4

3 回答 3

2

我不确定有什么内置的，所以我认为你必须做一些定制的东西......

这完全是假设性的，直接从我的脑海中浮现出来，但是：


  1. 获取您打开的连接的 SPID 并将其与反向更新的文本一起存储在某个临时表中。
  2. 使用后台进程（SSIS 或其他）来监视临时表并检查 SPID 是否仍然作为打开的连接存在。
  3. 如果连接断开，则后台进程可以执行存储的恢复命令
  4. 如果连接正确完成，则可以从临时表中删除 SPID，以便在连接关闭时后台进程不再恢复它。

欢迎评论或改进！

于 2011-03-10T18:44:38.187 回答
1

我将扩展我的评论。一般来说，我认为你应该重新考虑你的方法。所有数据库访问代码都应该打开一个连接，执行一个查询，然后关闭连接，您依赖连接池来减少打开大量数据库连接的开销。

如果是我们讨论的单个 SQL 命令，其操作的行不应该改变，那就是事务隔离级别应该处理的问题。为此，您可以调查 SQL Server 2005+ 中的快照隔离级别。

如果我们谈论的是作为长期运行事务的一部分的一系列查询，那就更复杂了，可以通过存储其他连接读取的事务状态来处理，以确定它们是否可以继续。沿着这条路走下去，您需要为用户提供工具，让他们可以取消可能不再适用的长时间运行的事务。

于 2011-03-10T19:12:05.007 回答
0

假设它甚至有可能......这只会在客户端机器在交易期间爆炸时对您有所帮助。此外，还有误报的风险——由于网络噪音，连接可能会中断几秒钟。

我将采取的方法是在另一台机器上启动一个进程，定期 ping 第一台机器以检查它是否仍然在线，然后在它变得无法访问时采取行动。

于 2011-03-10T18:45:18.803 回答