Blazkowiczзабыл никОднако нашел в комментариях интересный момент - "LLR (aka LPS / last participant support in WAS) introduces the risk of a heuristic hazard: if the 1PC resource does not respond (timeout, lost connection, etc.), there is no way to know what the outcome of the XA resource branches should be"
А мне теперь не понятно какое отношение к этому имеет оптимизация.
Ну пусть там будет 2 XA ресурса. Один делает commit, второй отваливается. Разницы никакой нет. Есть некая recovery стратегия, по ней такой failure и обрабатывается.

Так там 2 ресурса: один XA, второй нет (1 phase commit).

Вообще мы не так давно разбирались с темой 2PC против Paxos и потратили пару недель чтобы осилить. После этого я понял, что надо отвечать на вопрос на собеседовании "расскажите как работает 2PC" :)

Действительно, TM может (должен) вести доп. записи в локальном durable сторадже о том, будет ли он коммитить или откатывать конкретную транзакцию. Это нужно на тот случай если он сам помрёт после принятия такого решения. Далее high level recovery стратегия очень простая: просто делаем retry принятого решения по транзакции пока оно не пройдёт. Если какие-то TM/RM падают, просто ждём пока они переподнимуться и повторяем.

Теперь случай с 1PC. Чтобы понять в чём проблема, надо ОЧЕНЬ внимательно посмотреть на АПИ: http://docs.oracle.com/javase/1.5.0/docs/api/javax/transaction/xa/XAResource.html.

Видите метод recover? :) Если XA ресурс помер посредине коммита, то после рестарта TM получит с него список транзакций для recovery и будет делать для них commit/rollback. А вот с 1PC такого не сделаешься в виду отсутствия АПИ.

Пример - TM делает:

1. На XA - prepare, return success.
2. На 1PC - commit, случается таймаут.

Например 1PC уходит в оффлайн, потом перезапускается и TM не знает прошёл ли commit.