【问题标题】:SQL Server 2005: Why Name Transactions?SQL Server 2005:为什么要命名事务?
【发布时间】:2010-11-19 09:23:45
【问题描述】:

我一直在整理 SQL server 中的整个嵌套事务,并发现了这些对嵌套 trans 行为的理解的要点:

  • 嵌套事务时,只有 最外层的提交实际上会 提交。
  • “提交 Trans txn_name”,嵌套时 , 将始终适用于最里面 交易,即使 txn_name 指的是 到外部交易。
  • “ROLLBACK TRAN”(无名称),即使在 内部事务,将回滚 所有交易。
  • "ROLLBACK TRAN txn_name" - txn_name 必须 指最外面的 txn 名称。 否则,它将失败。

鉴于这些,命名交易有什么好处吗?您不能使用它来定位特定的事务,无论是提交还是回滚。 是否仅用于代码注释目的?

谢谢,

尤尼

【问题讨论】:

  • 另一个不值得回答 IMO 的原因是 here

标签: sql-server transactions nested-transactions


【解决方案1】:

您可以让程序在出错时仅回滚自己的工作,允许调用者决定是放弃整个事务还是恢复并尝试替代路径。请参阅Exception handling and nested transactions 以获取允许这种原子行为的过程模板。

【讨论】:

  • 真的吗?但是文档说你不能回滚内部嵌套事务,你只能回滚最外面的事务。我没有与您争论,因为我没有尝试过,我只是好奇它的实际工作方式。
  • 您可以回滚到一个保存点。我认为这与命名事务不同,但我认为这才是你真正想要的。
  • Remus - 关于保存点的要点。否则,(如果不使用保存点,我目前没有),没有好处?
  • 当事务嵌套不是开发人员所期望的嵌套事务时,命名事务可以捕获应用程序错误,因为如果组件试图回滚错误的名称,则会产生错误。
  • 好的,谢谢,这是有道理的。嵌套事务!= 保存点。
【解决方案2】:

这个想法是回滚您的部分工作,例如嵌套事务。并不总是按预期工作。 使用旧式错误处理和保存点的存储过程在与 TRY ... CATCH 块一起使用时可能无法按预期工作:Avoid mixing old and new styles of error handling.

已经在这里讨论过@@ERROR and/or TRY - CATCH

【讨论】:

  • 但它不会回滚您的部分工作。嵌套事务只会增加@@TRANCOUNT。回滚嵌套事务会回滚整个事务。除非你说的是存档点。
【解决方案3】:

实际上,它只是程序员的回忆录。如果您正在处理具有多个内部事务的 Tx,为每个有意义的名称提供有意义的名称可以帮助您确保事务被适当地嵌套并可能捕获逻辑错误。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-12-16
    • 2012-05-19
    • 1970-01-01
    相关资源
    最近更新 更多