存储过程和 SqlCommand 超时
如果我使用 SqlCommand 运行存储过程并且 SqlCommand 超时,StoredProc 会继续执行还是在 SqlCommand 断开连接时强制退出?
If I run a stored proc using the SqlCommand and the SqlCommand times out does the StoredProc continue to execute or does it get force to quit when the SqlCommand disconnects?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我的直觉告诉我该程序仍然会执行,所以我进行了一个简单的测试。
SQL:
在 VB.Net 中(与 C# 相同):
结果是什么? 该过程在超时后未完成。我检查了 SQL 探查器中的跟踪期间发生的情况,并且确实 SQL 似乎将调用包装在事务中,并且必须在超时时回滚该事务。
注意:此测试是针对 SQL 2005 运行的,但我怀疑其他版本的结果类似。
My instinct said that the procedure would still execute so I threw together a simple test.
SQL:
And in VB.Net (same as C# for this purpose):
The result? The procedure did not complete after the timeout. I checked what was happening during a trace in SQL profiler and sure enough SQL appears to wrap the call in a transaction and must roll that transaction back on the timeout.
Note: This test was run against SQL 2005 but I'd suspect the results to be similar in other versions.
正如布兰登所说,客户端发送“中止”并且处理停止。就这么简单。
然而,它比这更复杂......
默认情况下,任何事务都不会回滚,锁只会保留在那里,直到连接关闭。如果返回到连接池并重新使用,则这不算作关闭。
这就是为什么
SET XACT_ABORT ON
(其他问题SO1,SO2)As brendan stated, the client sends an "abort" and processing stops dead. As simple as that.
However, it's more complex than that...
Any transactions are not rolled back by default and locks are just left there until the connection is closed. If returned to the connection pool and reused, then this does not count as closing.
This is why
SET XACT_ABORT ON
(other questions SO1, SO2) is recommended