如果我在一个存储过程中调用另一个设置较低事务隔离级别的存储过程,可以吗?

发布于 2024-07-17 18:32:24 字数 720 浏览 11 评论 0原文

我有一堆实用程序,它们只检查数据库中的某些条件并返回标志结果。 这些过程以 READ UNCOMMITTED 隔离级别运行,相当于WITH NOLOCK。

我还有更复杂的过程,它们以 SERIALIZABLE 隔离级别运行。 他们也碰巧有同样类型的支票。

因此,我决定从这些复杂的过程中调用这些检查过程,而不是复制检查代码。

基本上它看起来像这样:

CREATE PROCEDURE [dbo].[CheckSomething]
AS
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

    BEGIN TRANSACTION

    -- Do checks

    COMMIT TRANSACTION

这样

CREATE PROCEDURE [dbo].[DoSomethingImportant]
AS
    SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

    BEGIN TRANSACTION

    EXECUTE [dbo].[CheckSomething]

    -- Do some work

    COMMIT TRANSACTION

做可以吗? 临时激活的较低隔离级别会以某种方式破坏较高级别的保护还是一切都完美安全?

编辑:执行顺利,没有任何错误。

I have a bunch of utility procedures that just check for some conditions in the database and return a flag result. These procedures are run with READ UNCOMMITTED isolation level, equivalent to WITH NOLOCK.

I also have more complex procedures that are run with SERIALIZABLE isolation level. They also happen to have these same kind of checks in them.

So I decided to call these check procedures from within those complex procedures instead of replicating the check code.

Basically it looks like this:

CREATE PROCEDURE [dbo].[CheckSomething]
AS
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

    BEGIN TRANSACTION

    -- Do checks

    COMMIT TRANSACTION

and

CREATE PROCEDURE [dbo].[DoSomethingImportant]
AS
    SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

    BEGIN TRANSACTION

    EXECUTE [dbo].[CheckSomething]

    -- Do some work

    COMMIT TRANSACTION

Would it be okay to do that? Will the temporarily activated lower isolation level somehow break the higher level protection or is everything perfect safe?

EDIT: The execution goes smoothly without any errors.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

墨小沫ゞ 2024-07-24 18:32:24

SQL Server 2005 的全部都在这里。片段:

当您更改一笔交易时
到另一个资源的隔离级别
更改后读取的内容是
根据规则受到保护
新的水平。 已阅读的资源
改变之前继续
根据规则受到保护
之前的水平。 例如,如果一个
事务从 READ 更改
致力于串行化,共享
更改后获取的锁是
现在一直持续到年底
交易。

如果您发出 SET TRANSACTION ISOLATION
存储过程中的 LEVEL 或
当对象返回时触发
控制隔离级别重置
到对象时有效的级别
被调用。 例如,如果您设置
批量重复读取,并且
批处理然后调用存储过程
将隔离级别设置为
SERIALIZABLE,隔离级别
设置恢复为可重复读取
当存储过程返回时
控制批次。

在此示例中:

  • 每个隔离级别都应用于存储过程的范围
  • DoSomethingImportant 锁定的资源保留在 SERIALIZABLE 下
  • CheckSomething 使用的资源是 READ UNCOMMITTED

It's all here for SQL Server 2005. A snippet:

When you change a transaction from one
isolation level to another, resources
that are read after the change are
protected according to the rules of
the new level. Resources that are read
before the change continue to be
protected according to the rules of
the previous level. For example, if a
transaction changed from READ
COMMITTED to SERIALIZABLE, the shared
locks acquired after the change are
now held until the end of the
transaction.

If you issue SET TRANSACTION ISOLATION
LEVEL in a stored procedure or
trigger, when the object returns
control the isolation level is reset
to the level in effect when the object
was invoked. For example, if you set
REPEATABLE READ in a batch, and the
batch then calls a stored procedure
that sets the isolation level to
SERIALIZABLE, the isolation level
setting reverts to REPEATABLE READ
when the stored procedure returns
control to the batch.

In this example:

  • Each isolation level is applied for the scope of the stored proc
  • Resources locked by DoSomethingImportant stay under SERIALIZABLE
  • Resources used by CheckSomething are READ UNCOMMITTED
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文