Как смоделировать сбой базы данных для проверки двухфазной фиксации в Java

Это много вопросов :) Постараюсь дополнить предыдущие ответы.

Is there a better way to simulate the DB failure?

Проверка всех случаев сложна. Один из способов проверить основные случаи - создать соединитель JCA (драйвер БД является соединителем JCA). Вы можете получить подключения от коннектора, который будет включен в транзакцию (третий участник). В этом случае соединение может вызвать определенные ошибки.

Есть три части, которые работают вместе: (1) приложение, (2) приложение. диспетчер транзакций сервера и (3) соединитель jca (так называемый адаптер ресурсов).

Соединение подключается к транзакции через ManagedConnection.getXAResource. С помощью настраиваемого коннектора jca вы можете затем вызвать исключение для приложения (Connection на рисунке) или диспетчера транзакций сервера приложений (XAResource получено с помощью ManagedConnection на рисунке). В частности, вы можете генерировать исключение во время XAResource.prepare и XAResource.commit, что соответствует ошибкам во время 2-фазной фиксации.

Обратите внимание, что трудно контролировать порядок привлечения участников (см. этот вопрос). Так что легко проверить, что один из 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 может уведомлять диспетчер транзакций. Одно из уведомлений - ConnectionEvent.CONNECTION_ERROR_OCCURRED, информирующее о том, что при использовании этого конкретного соединения произошла ошибка.

Как отмечено в другом ответе, обычно с каждой транзакцией связано одно управляемое соединение. Управляемое соединение абстрагирует физическое соединение, и вы не хотите использовать слишком много. Приложение получает только «ручки» (Connection на картинке). Все дескрипторы, полученные в рамках одной данной транзакции, указывают на одно и то же управляемое соединение. Это оптимизация, которую поддерживает большинство серверов приложений.

Если управляемое соединение становится недействительным, дескрипторы, которые его используют, также становятся недействительными. Но ручки AFAIK не могут быть "обновлены". Транзакция должна откатиться, управляемое соединение разрушено. Когда начинается другая транзакция, она будет связана с другим допустимым управляемым соединением из пула.

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?

Сервер приложений управляет пулом управляемых подключений. Как сказано в предыдущем абзаце, во время использования он может испортиться. Но можно испортиться и без использования. Например, используемое управляемое соединение в пуле может стать недействительным, поскольку истекло время ожидания базового физического соединения. На серверах приложений обычно есть возможность проверить, действительно ли управляемое соединение, прежде чем оно начнет его использовать. В противном случае он попробует другое управляемое соединение из пула или создаст новое.

Вероятно, вы можете добавить свой собственный ресурс, который будет участвовать в фиксации и приостанавливать транзакцию после первой фазы. А пока можно «вытащить вилку».

Андрей ответил на одну часть вопроса, поэтому позвольте мне ответить на вторую часть.

Объект Connection, который вы получаете в своем приложении, является лишь оболочкой физического соединения. Эта оболочка играет роль в создании пула соединений и управлении транзакциями. Если что-то пойдет не так с БД, оболочка соединения станет непригодной для использования, и вы сможете только выполнить откат. Это имеет смысл, потому что вы получаете доступ к соединению только до запуска 2PC, и все, что было сделано до запуска 2PC, невозможно восстановить.

Обратите внимание, что попытка разорвать соединение и получить новое ничего не меняет, потому что после того, как соединение из заданного источника данных было использовано в транзакции, вы всегда будете получать такое же соединение из этого источника данных, пока вы находитесь в та же сделка. Это означает, что ваше приложение не может «повторно подключиться» без перезапуска всей транзакции.

С другой стороны, если что-то пойдет не так после того, как все ресурсы будут подготовлены, но до того, как все ресурсы будут зафиксированы, то ответственность за восстановление транзакции лежит на диспетчере транзакций. Но это происходит негласно, и ваше приложение не контролирует ситуацию. Также на этом этапе ожидается, что ваше приложение освободит все соединения, используемые в этой транзакции.

Лучше всего, вероятно, использовать в базах данных памяти. Вызовите сбой и проверьте состояние источников данных до и после, чтобы убедиться, что откат / фиксация выполнены правильно.

Что касается других ваших проблем, это похоже на тесты с чрезвычайно высокой стоимостью / низким вознаграждением. Прочтите документацию поставщиков и убедитесь, что ваша транзакционная среда настроена должным образом. После того, как это будет сделано, вам, вероятно, следует автоматизировать его, чтобы не было никаких проблем.

Если вы не написали свой собственный менеджер транзакций для протокола 2PC + реализацию БД, я бы оставил тестирование этих функций вашему поставщику.