CREATE TABLEをロックする

別のアプリケーションでは、設計が悪いことに感銘を受けました。複数のスレッドがEnsureDatabaseSchemaExists()メソッドを同時に実行します。これは基本的に次のようになります。

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'MyTable') AND type = N'U') BEGIN

    CREATE TABLE MyTable ( ... );

END

ただし、SERIALIZABLEトランザクションで実行された場合でも、このコードはスレッドセーフではないようです（つまり、並列コードはテーブルを複数回作成しようとします）。別のスレッドがまったく同じSELECTステートメントを実行できないようにするロックを取得するためにSELECTステートメントを強制する機会はありますか？

multi-threaded-EnsureSchemaExists（）メソッドのより良いパターンはありますか？

最善の策は、明示的な包含トランザクションを使用し、カスタム排他ロックを取得して、sp_getapplockを使用して操作全体（SELECTおよびCREATE TABLE）を保護することです。システムオブジェクトは、設計上、分離レベルの要求を尊重せず、ユーザーテーブルと同じ方法でロックを使用します。

元のコードの競合状態は、複数のスレッドがテーブルが存在しないと結論付ける前に、スレッドがCREATE TABLEステートメントに到達することです。

私の推奨事項は、ベストエフォートのtry / catchを行うことです。必要に応じて、重複するケースを明示的に処理します。それを無視します...

本当の質問：なぜDDLは複数のxactからオンデマンドで実行されるのですか？通常、アップグレードと移行は深刻な問題であり、専用の時間枠で処理されます...移行（コードファースト？）が予期せず開始されないように、これらの更新手順の一部は大きなテーブル（サイズの-データ操作...）