再问存储过程内的锁

[飞啊飞的菜菜鸟]

CREATE PROCEDURE [dbo].[ToRecord9] @cSOCode VARCHAR(10)
AS 
select * from table1 (with TABLOCKX)
 
    BEGIN TRY
        SET xact_abort ON
    BEGIN TRAN
         UPDATE table1 SET F1=0----上面那个锁不影响这里的更新操作吗？从目前事实上来看好像毫无影响，但这从理论上好像解释不通啊
    COMMIT TRAN
    END TRY
    BEGIN CATCH
              PRINT CAST(@@TRANCOUNT AS CHAR(10)) + '捕获错误'
              IF (@@TRANCOUNT > 0)
              PRINT ERROR_MESSAGE()
    ROLLBACK TRAN
    END CATCH   

虽然给table1上锁了，但不影响同一事务本身里的操作，是这样吗？

[發糞塗牆]

测试了一下，不会影响，但是就你这个例子而言，前提是要等第一个select完毕之后后面才能操作，因为你这个锁是表级排它锁，同一个存储过程（可以理解为同一个事务）内，其他操作无法访问和操作这部分资源

[飞啊飞的菜菜鸟]

引用 1 楼 DBA_Huangzj 的回复:

测试了一下，不会影响，但是就你这个例子而言，前提是要等第一个select完毕之后后面才能操作，因为你这个锁是表级排它锁，同一个存储过程（可以理解为同一个事务）内，其他操作无法访问和操作这部分资源

版主就是负责任，还亲自帮我测试，而且很高效啊。 那就是说排他锁排的只是当前这一事务外的，对当前事务内的，只要上锁时的语句已操作完毕就可以了。（不过肯定已操作完毕才对，不然的话，应该不会执行到后面去吧，如本例的select * from table1 (with TABLOCKX)）

[發糞塗牆]

看图，我在右边的窗口中select，为了模拟大表，所以不提交，然后在左边窗口update，一直处于blocking状态，

[發糞塗牆]

这种排它锁更应该是排别的事务，而不是事务内的事务

[飞啊飞的菜菜鸟]

引用 4 楼 DBA_Huangzj 的回复:

这种排它锁更应该是排别的事务，而不是事务内的事务

好！