Транзакционны протокол

Для корректной совместной работы координатора и ресурсов в рамках транзакции необходимо согласование действий или протокол, который регламентирует набор и порядок взаимных вызовов (сообщений) между координатором и ресурсами. Существует несколько подходов для организации общения между координатором и ресурсами – несколько протоколов. Наиболее известный среди них – это протокол двухфазной фиксации (two phase commit). Однако, это не единственный протокол и вообще существует понятие n-фазной фиксации.

На sequence diagram показаны вызовы и их порядок для одного координатора транзакций и двух ресурсов. В конце транзакции, когда координатор получает от прикладного приложения указание зафиксировать транзакцию, координатор рассылает всем зарегистрированным ресурсам сообщение prepare, после чего ожижает ответ от всех ресурсов в течении установленного таймаута. Каждый ресурс, получив сообщение prepare, по протоколу обязан сохранить результаты работы в таком виде, что бы при последующем получении сообщения commit, правильная фиксация была бы гарантирована. Иными словами, ресурс первоначально согласившийся зафиксировать транзакцию, не может изменить своего решения. Для того, чтобы гарантировать устойчивость результатов транзакции (т.е. для того, чтобы результаты работы не пропали в случае сбоя), ресурс сохраняет результаты работы транзакции во временное хранилище, обычно – это так называемый transaction log, однако, физически, записи могут размещаться пока только в логе, но не в реальных таблицах и т.п., так как до получения окончательного commit ресурс не должен записывать окончательные результаты и делать их доступными для других транзакций. После получения положительного сообщения prepared ото всех ресурсов, координатор рассылает всем ресурсам сообщение commit, которое фиксирует результаты работы транзакции на каждом ресурсе. Если же какой либо из ресурсов на сообщение prepare отвечает rollback, то координатор рассылает всем ресурсам сообщение rollback. Такой протокол гарантирует, что если не происходит сбоев в самой инфраструктуре транзакций, то даже при сбое сети, или отключении питания одной или всех компонент участников транзакции, система останется в целостном состоянии, т.е. либо в состоянии на момент до начала выполнения транзакции, либо на момент после выполнения, т.е. на момент фиксации.

Если какой либо из ресурсов в ответ на посылку сообщения prepare присылает rollback, то координатор вызывает rollback на каждом из ресурсов. Во время выполнения транзакции, если она была начата координатором только тот координатор который начал транзакцию имеет право инициировать фиксацию (commit) или откат (rollback) этой транзакции. Если какой либо ресурс, например соединение с БД (например внутри хранимой процедуры, которая выполняется в рамках такой транзакции) попытается инициировать фиксацию, то такой вызов должен возвратить ошибку и фактическая фиксация произведена не будет.

Однако, сущетсвеут механизм, который позволяет ресурсу или любому другому компоненту участвующему в транзакции пометить текущую транзакцию как подлежащую только откату (mark for rollback only), это устанавливает статус контекста транзакции в значение MarkedForRollback и такая транзакция никогда не будет зафиксирована, даже если кто-либо вызовет метод commit координатора.

Важным моментом обеспечения транзакционности и согласованности действий координатора и ресурсов, является ведение журнала транзакций как координатором, так и каждым ресурсом в отдельности. Перед тем как отправлять сообщения ресурсам координатор всегда записывает текущий статус транзакции в лог. Таким образом, если после отправки сообщения commit, обрывается связь или прекращается процесс координатора (например аппаратный сбой на машине, где запущен координатор транзакций), то факт того что координатор разостал всем участникам сообщение commit и то что транзакция считается зафиксированной, не будет утерян и при восстановлении процесса координатора он свяжется с каждым из участников транзакции и проверит выполнился ли commit у них. При этом, согласно протоколу все участники транзакции получив сообщение prepare обязаны держать блокировки на объекты задействованные в рамках текущей транзакции до поступления сообщения commit или rollback. Иными словами, если в процессе транзакции, например, заблокированы некоторые таблицы или записи в БД, то эти записи должны оставаться заблокированными даже если координатор транзакции аварийно завершил работу. Это может привести к тому, что данные в БД могут оказаться недоступными для других пользователей на протяжении неопределённо долгого промежутка времени. В связи с этим, многие ресурсы выполняют так называемые эврестические действия, т.е. сами, без участия координатора принимают решения фиксировать или откатывать транзакцию. Например БД может решить, что если от координатора в течении определённого промежутка времени после поступления сообщения prepare не поступает ни сообщения rollback, ни сообщения commit, ресурс принимает решение о том что транзакция была отменена и следует выполнить откат. В любом случае, это решение попадает в транзакционный лог ресурса. Как только связ восстановится, или процесс координатора восстановится, координатор сравнит принятые решения каждого ресурса и координатора, и если они совпадут, то транзакция считается успешно завершенной или отменённой (в зависимости от решения commit или rollback). Если же решения не совпадают, то координатор транзакций генерирует сообщение об ошибке (exception), которое может быть:

• Heuristic Commit – говорит о том, что ресурс(ы) приняли решение зафиксировать транзакцию, не дождавшись комманды координатора.
• Heuristic Rollback – аналогично вышеуказанному, но ресурсы приняли решение откатить транзакцию, не дождавшис координатора.
• Heuristic Mixed – возникает в случае когда один из ресурсов принимает решение зафиксировать транзакцию, в то время как другие ресурсы или координатор принимают решения откатить и наоборот.
• Heuristic Unknown – возникает в ситуации когда несколько ресурсов и координатор решают по разному фиксировать транзакцию или откатывать.

В случае эвристического фиксации или отката, координатору остаётся только удостоверится в правильности и единогласности принятого решения, после чего постать сообщение forget участникам транзакции, с тем, чтобы они могли очистить свои журналы транзакций. В случае смешанного или неопледелённого эвристического результата, как правило требуется вмешательство человека оператора, так как эти ошибки могут указывать на нарушение целостности данных (например средства были списаны с одного счёта в одной БД но не занесены на другой счёт в другой БД, что привело к потери средств, фактически в никуда). Если такие ошибки будут обнаружены человеком оператором, их следует скорректировать компенсационными транзакциями (например, вручную внести средства назад на исходный счёт).

Дата добавления: 2014-01-05