これまでに見たすべての SQL デッドロックの例では、SELECT/UPDATEなどの実行中にデッドロックが発生しました。
すべてのステートメントが正常に実行された場合、次のときにデッドロックが発生する可能性はありますCOMMITか?
ORM でデッドロック例外をキャッチしようとしていますが、使用するだけで十分かどうか、またはラップする必要があるかどうか疑問に思ってtry{}いflush()ますcommit()。
これまでに見たすべての SQL デッドロックの例では、SELECT/UPDATEなどの実行中にデッドロックが発生しました。
すべてのステートメントが正常に実行された場合、次のときにデッドロックが発生する可能性はありますCOMMITか?
ORM でデッドロック例外をキャッチしようとしていますが、使用するだけで十分かどうか、またはラップする必要があるかどうか疑問に思ってtry{}いflush()ますcommit()。
はい、COMMIT を実行するとデッドロックが発生する可能性があります。より正確には、アプリケーションが COMMIT を実行すると、デッドロックが通知される場合があります。
接続 A で、一連の操作を実行するとします。独立して、別の接続 (接続 B) がデッドロックを引き起こすいくつかのことを行い、DBMS は接続 A をロールバックすることを決定します。
ただし、接続 A は実行したいことをすべて実行したので、COMMIT を決定します。これは、DBMS がロールバックの実行を決定した後、クライアントが接続 A で実行する最初の操作であるため、その時点で通知を受け取ります。
COMMIT であっても、すべての操作でエラーを処理する必要があります。