それはたくさんの質問です:)私は前の答えを完成させようとします。
Is there a better way to simulate the DB failure?
すべてのケースのテストは複雑です。主なケースをテストする1つの方法は、JCAコネクタを作成することです（DBドライバはJCAコネクタです）。トランザクションに参加するコネクタ（3番目の参加者）から接続を取得できます。その後、接続によって特定のエラーが発生する可能性があります。
連携する3つの部分があります：（1）アプリケーション、（2）アプリ。サーバーのトランザクションマネージャー、および（3）jcaコネクター（いわゆるリソースアダプター）。
接続は、を介してトランザクションにフックしManagedConnection.getXAResourceます。カスタムjcaコネクタを使用すると、アプリケーション（Connection画像内）またはアプリケーションサーバーのトランザクションマネージャ（画像内XAResourceから取得）に例外を発生させることができますManagedConnection。特に、との間に例外をスローできますXAResource.prepare。これは、2フェーズコミット 中XAResource.commitのエラーに対応します。
参加者のエンリメントの順序を制御するのは難しいことに注意してください（この質問を参照）。したがって、失敗の1つ（つまり、あなたの失敗）をテストするのは簡単prepareですが、それらが呼び出される順序を制御するのは困難です。2フェーズコミットのすべての可能な無効な状態を再現することは、特に最適化を実行する場合は複雑です。
（私はかつてJCAコネクタ（http://code.google.com/p/txfs）を作成しましたが、サンプルコードが必要な場合は、他にもあります。）
What happens to the connection object when DB connection goes bad?
Does it retain its value or does it become null?
はManagedConnectionトランザクションマネージャに通知できます。通知の1つは、ConnectionEvent.CONNECTION_ERROR_OCCURREDこの特定の接続を使用しているときにエラーが発生したことを通知することです。
他の回答で述べたように、通常、トランザクションごとに1つの管理対象接続が関連付けられています。管理された接続は物理的な接続を抽象化するので、あまり多く使用したくありません。アプリケーションは「ハンドル」（Connection写真）のみを取得します。1つの特定のトランザクション内で取得されるハンドルはすべて、同じ管理対象接続を指します。これは、ほとんどのアプリサーバーがサポートする最適化です。
管理対象接続が無効になると、それを使用するハンドルも無効になります。ただし、ハンドルを「更新」することはできません。トランザクションはロールバックする必要があり、管理対象接続は破棄されます。別のトランザクションが開始されると、プールからの別の有効な管理対象接続に関連付けられます。
What actually happens when application tries to reconnect to DB?
What value does connection object get?
Does it use an existing value from the connection pool?
アプリサーバーは、管理対象接続のプールを管理します。前の段落で述べたように、それが使用されている間、人は悪くなるかもしれません。しかし、使われずに悪くなることもあります。たとえば、基になる物理接続がタイムアウトしたため、プールで使用されている管理対象接続が無効になる場合があります。通常、アプリサーバーには、管理対象接続が有効かどうかをテストしてから使用を開始する機能があります。そうでない場合は、プールから別の管理対象接続を試行するか、新しい接続を作成します。