トランザクション メッセージング

Service Broker プログラミング モデルは、トランザクション メッセージングを基盤にしています。Service Broker に関連するすべての操作は、現在のトランザクションの一部です。Service Broker では、現在のトランザクションがコミットされるまでは、メッセージング操作がコミットされません。トランザクションがロールバックされると、トランザクションの一部であるすべてのメッセージング操作もロールバックされることが、データベース エンジンによって保証されます。アプリケーションは、SQL Server のトランザクションの管理の一環として、メッセージング操作を管理します。

たとえば、あるプログラムからトランザクション内でメッセージを送信するときは、そのプログラムでトランザクションがコミットされるまでは、Service Broker はネットワーク経由でメッセージを送信しません。プログラムがトランザクション内でメッセージを受信するときは、そのプログラムでトランザクションがコミットされるまでは、データベース エンジンではメッセージがキューから完全には削除されません。

トランザクション メッセージングは、データベースの状態とキューの状態の一貫性を保ったまま、堅牢でスケーラブルなアプリケーションを記述する場合に役立ちます。アプリケーションでデータベースに変更を加え、メッセージを送信または受信する場合、データベースへの変更とメッセージング操作は同じトランザクションの一部になります。トランザクションがロールバックされると、データベースへの変更とメッセージング操作の両方がロールバックされます。両方とも操作が成功するか、または両方とも操作が失敗します。Service Broker モデルでは、アプリケーションによって送信されたメッセージがデータベースの現在状態を反映することを保証するために、アプリケーションでトランザクション メッセージングが使用されます。

トランザクション メッセージングを完全に利用するには、メッセージが表すデータベース操作と同じトランザクション内でメッセージング操作が行われるようにアプリケーションを作成します。たとえば、注文を処理するアプリケーションでは、1 つのトランザクション内で注文に関するメッセージを受信し、その注文でデータベースを更新するようにします。

あるトランザクションでメッセージを受信し、別のトランザクションでデータベースを更新する場合、データベースの更新が失敗すると、メッセージは既に存在しなくなったのに、そのメッセージによって要求された変更が行われないという状況になります。このような場合は、Service Broker で提供されている主な利点の 1 つが利用されていません。特に、Service Broker では、すべてのメッセージが 1 回だけ、正しい順序で配信されることが保証されています。この配信の一貫性が保証されない場合は、Service Broker エラー メッセージがメッセージの送信者に通知されます。この例のように、キューから完全にメッセージを削除するアプリケーションがメッセージの処理に失敗した場合、この配信の一貫性が保証されません。配信の一貫性が保証されない場合は、可能性のある不一致を処理する追加コードがアプリケーションに含まれているか、不適切な結果によるリスクを抱えてアプリケーションを実行する必要があります。

アプリケーションでメッセージが処理され、データベースに変更が加えられなければ、配信の一貫性の保証は保持されます。メッセージは正常に処理されます。Service Broker を使用するアプリケーションでは、メッセージを無視することはできますが、データベースへの接続が失われたり、または予想外に終了しても、メッセージが失われてはいけません。