Spring の @Transactional Shape トランザクション動作における分離パラメータと伝播パラメータはどのように行われるのでしょうか?

Spring の @Transactional における分離と伝播のダイナミクスを理解する

Spring の @Transactional アノテーションは、トランザクションの動作をカスタマイズするための 2 つの重要なパラメーター、分離と伝播を提供します。これらのパラメーターを詳しく調べて、現実世界のシナリオにおけるその影響を調べてみましょう。

伝播: トランザクションの相互作用を制御する

伝播は、トランザクション間の関係を定義します。最も一般的なオプションは次のとおりです:

• REQUIRED: コードは既存のトランザクション内で実行されるか、存在しない場合は新しいトランザクションを開始します。
• REQUIRES_NEW: コードは常に新しいトランザクションを開始し、既存のトランザクションを一時停止します。

通常、REQUIRED はほとんどのシナリオに対応します。ただし、トランザクションの完全な分離を保証することが最重要である場合は、REQUIRES_NEW が適切です。

分離: データ整合性の維持

分離では、トランザクションが相互に対話する方法を指定することでデータの整合性が保証されます。主なオプションは次のとおりです:

• ISOLATION_READ_UNCOMMITTED: 「ダーティ リード」を有効にします。これは、他のトランザクションからのコミットされていない変更が表示されますが、ロールバックされる可能性があります。
• ISOLATION_READ_COMMITTED: ダーティ リードを防止し、他のトランザクションからコミットされた変更のみが表示されるようにします。
• ISOLATION_REPEATABLE_READ: トランザクション内の同じ行の複数の読み取りが同じ値を返すことを保証します。たとえ、その間に他のトランザクションが行を変更したとしても。
• ISOLATION_SERIALIZABLE: トランザクションを順番に実行し、同時実行関連のデータの不整合を排除します。

より厳密な分離レベル (SERIALIZABLE など) のマイナス面は、マルチスレッド アプリケーションでのパフォーマンスの低下です。したがって、アプリケーションのニーズに基づいてトレードオフを慎重に検討することをお勧めします。

実際の例

ダーティ リードによるデータ競合からの保護:

ダーティ リードの典型的な例は、スレッド 1 がデータベース行に値を書き込み、トランザクションをロールバックしてデータベースに古い値を残すときに発生します。スレッド 2 が同時に行を読み取ると、(現在は正しくない) 古い値が表示されます。このような不一致を防ぐために、ISOLATION_READ_COMMITTED を使用できます。

トランザクション分離の強制:

REQUIRES_NEW 伝播の実際のアプリケーションは、常に完全に実行される必要があるサービス メソッドにあります。孤立したトランザクション。次の方法を検討してください。

<code class="java">@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
    repo1.retrieveFoo();
    repo2.retrieveFoo();
}</code>

この方法では、リポジトリ repo1 および repo2 に加えられた変更が他のトランザクションから確実に隔離され、潜在的な干渉が防止され、データの一貫性が維持されます。

以上がSpring の @Transactional Shape トランザクション動作における分離パラメータと伝播パラメータはどのように行われるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。