Журналы транзакций Atomikos com.atomikos.icatch.enable_logging=false

Я хотел бы понять, будут ли возможности распределенных транзакций работать для моего приложения, если я установлю com.atomikos.icatch.enable_logging=false

  • Правильно ли я понимаю, что Transaction Recovery актуален в тех случаях, когда произошел сбой, и мы хотим полностью перезапустить ту же транзакцию.
  • Работает ли восстановление в рамках одной и той же распределенной транзакции?
  • Мое приложение терпимо к сбоям в том смысле, что сбой всегда можно просто перезапустить с самого начала с новой транзакцией. Означает ли это, что в моем случае можно установить com.atomikos.icatch.enable_logging=false
  • Может ли com.atomikos.icatch.enable_logging=false привести к несогласованному состоянию базы данных, если не все участники распределенных транзакций были зафиксированы?

Обновление После этой проблемы я был вызван, чтобы узнать немного больше о внутренних компонентах распределенных транзакций, которые я описал здесь: Как бы вы настроили транзакцию Distributed ( XA ) для повышения производительности?


java database distributed-transactions xa atomikos
person Alexander Petrov    schedule 19.12.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Ну, мне потребовалось некоторое время, чтобы понять это. Ответ: НЕТ, если мы отключим com.atomikos.icatch.enable_logging, мы не сможем гарантировать согласованность транзакций, и мы можем получить некоторые вещи, зафиксированные в одной базе данных и не зафиксированные в другой.

В транзакции XA у нас есть две основные роли. Координатор сделки и участник сделки. Задействованы два журнала транзакций. Журнал транзакций Координатора с одной стороны и лог транзакций участника.

Происходит следующее: сначала все участники транзакции XA регистрируются у координатора. XA_START затем следует фаза записи, на которой все операторы sql отправляются разным участникам. XA_END отмечает конец этого процесса и момент, когда с точки зрения приложения вызывается фиксация.

В этот момент координатор транзакций берет на себя управление за кулисами. Каждому участнику отправляется сообщение PREPARE. Каждый участник отвечает READY TO COMMIT или ABORT, сообщение принудительно заносится в журналы. Если все участники ответят COMMIT. Вызов фиксации отправляется каждому участнику.

Это означает, что в случае сбоя и отключения ведения журнала транзакций на стороне координатора, которым является Atomikos, существует большая вероятность того, что одному участнику удастся зафиксировать, а другому участнику не удастся зафиксировать.

По сути, com.atomikos.icatch.enable_logging является обязательным, если вы хотите гарантировать согласованное состояние.

person Alexander Petrov    schedule 21.02.2017

arrow_upward
0
arrow_downward

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

person Guy Pardon    schedule 30.12.2016
comment
Я не думаю, что это достаточно подробно. То же самое я могу прочитать на веб-сайте атомикоса. - person Alexander Petrov; 09.01.2017
comment
Точно. Вот почему веб-сайт является авторитетным источником :-) - person Guy Pardon; 10.01.2017
comment
Отлично, почему бы вам не объяснить, как восстановить транзакцию в деталях :) Использование и алгоритм, если вы это сделаете, 100 баллов ваши :) - person Alexander Petrov; 11.01.2017
comment
На самом деле я только что подробно описал алгоритм здесь: stackoverflow.com/questions/49109373/ - person Alexander Petrov; 05.03.2018