TransactionScope 内的 SqlException
我目前正在开发 VB.NET 2.0 中的遗留项目。 该项目有一个非常有趣的 DAL 层，它不包含事务：-| 不管怎样，我的工作是让程序的某些部分具有事务性，但我不这样做 可以访问DAL层代码。 因此，我尝试将整个代码段放入单个 TransactionScope 中。
现在问题来了： 当 SqlException 从 DAL 层深处的某个地方抛出时，我的事务总是会回滚！即使我捕获并处理同一个 TransactionScope 内的异常。
我的问题：这是正常行为吗？ 我能做些什么吗？
我认为当异常抛出超出 TransactionScope 的范围时事务回滚是正常的，但如果在这些范围内处理异常则不会回滚！
任何帮助将不胜感激！
编辑：SqlException实际上是从System.Data.Common.SqlCommand内部抛出的，所以我无法真正阻止它的发生。
问候， LDX
I'm currently working on a legacy project in VB.NET 2.0.
The project has a very funny DAL-layer which does not incorporate transactions :-|
Anyway, it's my job to make some parts of the program transactional and I don't
have access to the DAL layer code.
So I'm trying to put entire sections of code inside single TransactionScope.
Now here's the problem:
When an SqlException is thrown from somewhere deep down in the DAL layer, my transaction always gets rolled back! Even if I catch and handle the exception inside that same TransactionScope.
My question: Is this normal behaviour?
and is there anything I can do about this?
I think it's normal that the transaction is rolled back when an exception gets thrown beyond the bounds of the TransactionScope, but not if the exception is handled within those bounds!
Any help would be much appreciated!
Edit: The SqlException is actually thrown from within a System.Data.Common.SqlCommand, so I can't really stop it from occurring.
Regards,
ldx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，我将收回我在下面得到的答案，我已经将其编辑掉，以避免不必要地让任何人感到困惑...:)
经过更多测试，我确定如果正常的异常被捕获并处理（不重新抛出） ）交易将按预期完成。某些类别的异常（例如参与该事务的 sql 异常）可能始终会使根范围中的事务无效，即使已处理，但我尚未对此进行测试，因此无法证实该理论。
对不起！
Well, I am going to retract the answer I had below, which I've edited out to avoid confusing anyone more than neccessary... :)
After more testing, I determined that if normal exceptions are caught and handled (not re-thrown) the transaction would completed as expected. It may be that certain classes of exceptions (such as sql exceptions participating in that transaction) may always invalidate the transactions in the root scope even if handled, but I haven't tested that so can't confirm that theory.
Sorry!