5 sql t-sql sql-server sql-server-2005
抱歉,最后一条消息.我对我的问题做了一个粘贴.长问题很简单,当在try/catch块中使用sp_GetAppLock时,是否应该在捕获到异常时调用sp_ReleaseAppLock?
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
BEGIN TRAN
DECLARE @res INT
EXEC @res = sp_getapplock
@Resource = 'This a Lock ID 3',
@LockMode = 'Exclusive',
@LockOwner = 'Transaction',
@LockTimeout = 60000,
@DbPrincipal = 'public'
if @res < 0
begin
declare @errorMessage nvarchar(200)
set @errorMessage =
case @res
when -1 then 'Applock request timed out.'
when -2 then 'Applock request canceled.'
when -3 then 'Applock involved in deadlock'
else 'Parameter validation or other call error.'endraiserror (@errorMessage,16,1)
end
SELECT...
INSERT...
UPDATE...
COMMIT TRANSACTION -- THIS RELEASES THE APPLOCK
RETURN 0; END TRY
BEGIN CATCH
-- ROLLBACK TRANSACTION IF NEEDED IF @@TRANCOUNT > 0 ROLLBACK
/* Exception handling stuff here. Should I call sp_releaseapplock? ... ... */
-- return the success code RETURN -1;
END CATCH
Run Code Online (Sandbox Code Playgroud)
当事务提交或回滚时,将释放与当前事务关联的锁.
所以,它不需要,因为你回滚.
但是,如果您想要安全,我会在CATCH块后执行此操作并首先使用APPLOCK_TEST进行测试.通常,这将是我们没有的最终块.
我在这里有它所以它总是被执行.如果会话继续,或者连接池使它保持活动状态(是吗?现在忘记了),那么如果它不是在退出之前就依赖于COMMIT/ROLLBACK.当然,任何错过CATCH块的东西都会成为一个严重的中止错误......
| 归档时间: |
|
| 查看次数: |
3338 次 |
| 最近记录: |