先に書いたエントリの、続きとして。
Deadlock detection
https://docs.jboss.org/author/display/ISPN/Infinispan+transactions#Infinispantransactions-Deadlockdetection
Enlisting Synchronization
https://docs.jboss.org/author/display/ISPN/Infinispan+transactions#Infinispantransactions-EnlistingSynchronization
同じく、英訳なのですが、デッドロック検出についてはこちらのドキュメントを見るのがよいかもですね。
18.7. デッドロックの検出
https://access.redhat.com/site/documentation/ja-JP/JBoss_Data_Grid/6/html-single/Administration_and_Configuration_Guide/index.html#sect-Deadlock_Detection
それでは、いってみます。
デッドロックの検出
特に多数のトランザクションが同じキーの集合に対して、繰り返し操作を行っている時、システムのスループットは
著しく（1桁上がるような、ベンチマークを参照）縮小する可能性があります。デッドロックの検出は、デフォルトでは無効です。しかし、次のように設定を加えることによって、キャッシュ毎に（例えば、namedCache設定配下）有効／無効を設定できます。
<deadlockDetection enabled="true" spinDuration="1000"/>
デッドロックの検出を有効にする時は、いくつかの手がかりがあります。TimeoutExceptionによりロールバックされるトランザクションの数が多いことは、この機能を助ける指標となります。
TimeoutExceptionは、他の原因で引き起こされるかもしれません。しかし、デッドロックはいつもこの例外が投げられるという結果になるでしょう。一般に、キーセット上で高い競争（競合？）がある時、デッドロックの検出は助けになるかもしれません。
しかし、ベストな方法はパフォーマンスの向上を推測するのではなく、ベンチマークを行い、結果を測定することです：
DeadlockDetectingLockManager MBeanによってエクスポートされた、JMXによる統計情報（例えば、検出されたデッドロックの数）にアクセスすることができます。どのようにデッドロックが検出するのか、ベンチマーク、そして設計詳細については、この記事（＊）を参照してください。
この記事（Increase transactional throughput with deadlock detection）
http://infinispan.blogspot.jp/2009/07/increase-transactional-throughput-with.html
注意：
デッドロック検出は、ひとつのキャッシュ上で動作します。2つ以上のキャッシュを跨ったデッドロックは、検出されないでしょう。
トランザクションと例外
もしCacheException（またはそのサブクラス）がJTAトランザクションのスコープの範囲でCacheのメソッドによりスローされた場合、そのトランザクションはロールバックのために自動的にマークされます。
ノードが失敗した時の、トランザクションのリカバリ
長いので、また今度…。
Transaction recovery
https://docs.jboss.org/author/display/ISPN/Transaction+recovery
Enlisting Synchronization
デフォルトでは、InfinispanはXAResourceによる分散トランザクションの、ファーストクラスの参加者として自分自身を登録します。しかし、ライフサイクル（準備、完了）により通知されるだけではなく、Infinispanがトランザクション中の参加者として要求されない場合があります。
例えば、InfinispanがHibernateの2次レベルキャッシュとして使用される場合です。
5.0のリリースから、InfinispanはトランザクションへのSynchronisationによる参加を許可できるようになりました。これは、transaction要素のuseSynchronization属性により有効にすることができます。
<transaction useSynchronization="true"/>
Synchronisationは、トランザクションに参加するリソースがただひとつである1PC（1フェーズコミット）の時、TransactionManagerは2PCを最適化することができるというアドバンテージを持ちます（最後のリソースである、コミットの最適化）。
例えば、Hibernateの2次レベルキャッシュ：
Infinispanが、コミット時のXAResourceとしてTransactionManagerに自身を登録していた場合、TransactionManagerは2つのXAResource（Cacheとデータベース）を参照し、この最適化を行いません。2つのリソースの間を調整する必要があり、トランザクションログをディスクに書き込む必要があります。一方で、InfinispanをSynchronisationとして登録することは、TransactionManagerにディスクへのログの書き込みをスキップさせることになります（パフォーマンスの向上）。
