Springの分散式事務は、XA-3を使用しますか？

原文のリンク:
http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html?page=3
Page 3 of 6
リスト1.事務のロールバック

@Transactional
  @Test
  public void testInsertIntoTwoDataSources() throws Exception {

    int count = getJdbcTemplate().update(
        "INSERT into T_FOOS (id,name,foo_date) values (?,?,null)", 0,
        "foo");
    assertEquals(1, count);

    count = getOtherJdbcTemplate()
        .update(
            "INSERT into T_AUDITS (id,operation,name,audit_date) values (?,?,?,?)",
            0, "INSERT", "foo", new Date());
    assertEquals(1, count);

    // Changes will roll back after this method exits

  }

上記の操作は更新エラーが発生した場合、関数が終了するとデータロールバックを実行します。 MulipleDataSourceTestsは、リスト2に示されるように、両方の動作がロールバックされているかどうかを確認する。
リスト2.ロールバック確認

@AfterTransaction
  public void checkPostConditions() {

    int count = getJdbcTemplate().queryForInt("select count(*) from T_FOOS");
    // This change was rolled back by the test framework
    assertEquals(0, count);

    count = getOtherJdbcTemplate().queryForInt("select count(*) from T_AUDITS");
    // This rolled back as well because of the XA
    assertEquals(0, count);

  }

Spring事務管理がどのように動作し、どのように構成されているかをよりよく理解するために、Spring参照ガイドを参照してください。
1段階を使って最適化したXA（XA with 1 PC Opitimization）を提出します。
このモードは最適化スキームであり、多くのトランザクションマネージャが単一のリソースのみを含む場合、2つのフェーズ（2 PC）によってもたらされるオーバヘッドを回避するために使用しています。アプリケーションサーバはこのような状況を判断することができる必要があります。
XAと最後の資源戦略（the Last Resource Gambit）
多くのXA事務マネージャのもう一つの特性は、一つのリソースを除いてすべての他のリソースがXA互換である場合にも、それらは同様にすべてのXAリソースと同じ障害回復保証を提供することができるということである。これは資源の順序付けと非XA資源の使用を通じて最終的に決定的な投票です。もしそれが失敗したら、他のすべてのリソースがロールバックされます。これは100%のバグ無しモードに近いです。また、失敗した場合は、追加の措置を採用しない限り、追跡情報はあまり残されません。
共有トランザクションリソースモード（Shared Transaction Resource pattern）
いくつかのシステムでは、複雑さを低減し、スループットを向上させるための良いモードは、すべてのトランザクションリソースが同じリソースによってサポートされることを確保することによって、XAの使用依存性を完全に除去することができる。これは明らかにすべてのシーンに適用される汎用モードではないが、XAと同じくらい丈夫で、しかもずっと速い。共有型トランザクションリソースパターンは、ホールがないが、特定のプラットフォームおよび処理シーンにのみ適用される。
このモードについては、簡単で多くの人がよく知っている例として、ORMを使ったコンポーネントと、JDBCコンポーネントを使ってデータベース接続を共有するというものがあります。これは通常、Hibernate、Eclipselink、およびJava Persistens API（JPA）のSpringトランザクションマネージャのようないくつかのORMツールを使用するときに発生する。同じトランザクションは、ORMとJDBCコンポーネントの間を安全に越えることができ、通常は上記の制御トランザクションのサービス層方法によって駆動される。
もう一つの効果的にこのモードを使用する例は、メッセージ駆動に基づく単一のデータベース更新である（本明細書で紹介した例と同じ）。メッセージ中間体システムは、それらのデータをどこかに記憶する必要があり、通常は関係型データベースである。モードに実装するために必要なのは、メッセージシステムのためにトラフィックデータを指定するだけで、同じデータベースを使用することになる。このモードは、メッセージ中間のベンダーがその格納ポリシーの詳細を暴露することに依存し、このようにメッセージ中間のコンポーネントを、統一されたデータベースと同じトランザクションにマウントするように構成することができる。
by iefreer