如果没有使用 try/catch 或异常逻辑来回滚,那么在事务中包装存储过程是否有意义?

Is there a point to wrapping a stored procedure in a transaction if no try/catch or exception logic to rollback is used?

我注意到我的公司有很多类似这样的存储过程脚本:

alter procedure MyProcedure
    @ItemID int
as
    BEGIN TRANSACTION
    -- Do some stuff, maybe only 1 insert/update statement, maybe many
    COMMIT TRANSACTION

重点是,没有 try/catch 块,也没有 'if' 回滚语句。回滚从未在代码中的任何地方使用

那么交易的意义何在?包装在我不知道的交易中还有其他好处吗?我一直以为原因是出了问题要用回滚

在这个程序的范围之外是否有逻辑赋予它意义?

鉴于我有限的知识,它不仅看起来毫无意义,而且看起来很危险,因为如果出现问题,提交将永远不会执行(对吗?),然后你有一个打开的事务并且 table无限期锁定。

如果更新中途失败,它将在会话关闭时回滚(更具体地说,未能提交,但相当于回滚)。详细讨论了here,但相关部分是:

Transactions ... Has no persistent effect whatever on the database, through: the action of the ROLLBACK Statement, abnormal termination of the client requesting the transaction, or abnormal termination of the transaction by the DBMS. This may be an action by the system (deadlock resolution) or by an administrative agent, or it may be an abnormal termination of the DBMS itself. In the latter case, the DBMS must roll back any active transactions during recovery.

基本上他们已经设置好了,所以程序永远不会部分执行。话虽如此,由于性能和锁定问题,这可能并不总是理想的方式,但如果没有更多细节我真的不能说。