SQL Server 2014 実践シリーズ （HTML 版）
「No.1 インメモリ OLTP 機能の実践的な利用方法」

2.15　ネイティブ コンパイル SP での更新競合への対応

インメモリ OLTP は、楽観的同時実行制御が実装されているので、同じデータを更新した場合には、更新競合（41302 エラー）が発生します。これは、次のような状況です。

実際の顧客マスターの更新は、前述したように主キー列を除いた全ての列データを更新していますが、説明を簡略するために、col3 とcol4 の更新のみにしています。また、この更新競合は、同じ(カードID, カード種別) に対する更新を、全く同時に行った場合にのみ発生するため、通常の運用では発生し得ない競合です。このお客様のポイントカード システムでは、同じカードID の操作は、特定の店舗（端末）での利用に絞られていて、同時に他の店舗から同じカードが利用されることはないからです。したがって、顧客マスターの更新においては、更新競合への対応をする必要はないのですが、他の処理で利用する場面はあり得るので、これを例に説明します。

◆ 更新競合への対応

更新競合への対応は、オンライン ブックの以下のトピックがそのまま利用できます。

メモリ最適化テーブルでのトランザクションの再試行ロジックのガイドライン
http://msdn.microsoft.com/ja-jp/library/dn169141(v=sql.120).aspx

このトピックでは、次のようにストアド プロシージャを作成する例が掲載されています。

ネイティブ コンパイル SP を実行するための、通常のストアド プロシージャを作成して、BEGIN TRY でネイティブ コンパイル SP を実行して、実行が成功したのか、失敗したのかを判断して、成功したら WHILE ループを抜けて終了、失敗した場合は、CATCH ブロックでエラー番号が更新競合かどうか（41302、41305、41325、41301、1205 かどうか）をチェックして、これらの番号なら再試行を行う、そうでない場合は THROW で、該当エラーをそのまま通達する、という流れになっています。

CATCH ブロックで処理しているエラー番号の意味は、次のとおりです。

これを、先ほどの顧客マスターの更新へ当てはめると、次のようになります。

後は、ADO.NET 側で、次のように、このストアド プロシージャを呼び出すように変更すれば完了です。

Tips：更新競合（41302）が多発する場合は、WAITFOR DELAY を設定
オンライン ブックのトピックにも記載されていますが、更新競合（41302 エラー）が多発する場合には、WAITFOR DELAY を設定して、タイミングを遅らせることも考慮することをお勧めします。

上記のように「WAITFOR DELAY '00:00:00.001'」と記述した場合は、1ミリ秒待機して、再試行が行えるようになります。
詳しくは第4章で説明しますが、ナンバリング処理を手動で行っている（連番を手動で生成している）ような場合には、同時実行の多重度が上がった場合に（50多重や 100多重になった場合に）、1ミリ秒待機したとしても更新競合が発生してしまうことがあるので、「'00:00:00.002'」のように 2ミリ秒へ変更したり、再試行回数（@retry）を 10 から 100 などへ増やしたりするなどの対応が必要な場合があります。
もちろん、これによって実行性能は低下することになるので、これを行うかどうかは処理の継続性とのトレードオフになります。そもそもナンバリング処理を手動で行うことを止めるという方法（IDENTITY やシーケンスを利用するなど）もあるので、更新競合が多発するような状況は、現在のロジックを見直して、更新競合を避けるようなアプリケーション設計へ変更するチャンスとも言えます。