Каково различие между координатором транзакции и менеджером транзакций?

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

Говоря языком TP, « диспетчер транзакций » - это то, что выдает запросы фиксации / отката для «диспетчеров ресурсов». «Диспетчер ресурсов» - это что-то вроде системы управления базами данных, которая изменяет состояние транзакциями. Двухфазная фиксация - это протокол, в котором диспетчер транзакций проверяет, что все диспетчеры ресурсов могут гарантировать фиксацию транзакции (т. Е. иметь записи журнала, записанные в постоянное хранилище, и нет условий ошибки, которые могли бы предотвратить фиксацию), а затем сообщает фиксацию. Затем он проверит, что транзакция была подтверждена всеми менеджерами ресурсов, прежде чем пометить транзакцию как «подтвержденную».

Координатор транзакции - это часть системы, которая обрабатывает этот процесс фиксации. Это может быть та же программа, что и Transaction Monitor, а может и не быть. Примером координатора транзакций является MS DTC (координатор распределенных транзакций). Это немного интересно, поскольку в этой архитектуре ( MTS / COM + ) он фактически запускается как отдельный процесс.

Transaction Manager или TP Monitor - это подсистема, которую приложение использует для управления фиксацией транзакции / откат процесса. На нем размещается средний уровень приложения, и предоставляет API-интерфейсы для получения идентификаторов транзакций и голосования для фиксации / отката транзакции. Если в голосовании участвует только один процесс, это эквивалентно сообщению о фиксации / откате. В кругах Java это часто называют «сервером приложений» (или иногда «контейнером компонентов» при использовании EJB). Примерами менеджеров транзакций являются MS Transaction Services (позже известные как COM + Transaction Services), CICS и различные серверы приложений Java.

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

Из-за разрыва соединения с базой данных фиксация и откат должны контролироваться вне полосы со среднего уровня через другой протокол. Это роль протокола XA (из стандарта XOpen) или протокола транзакций OLE.

Запросы фиксации / отката к диспетчеру ресурсов не обязательно должны исходить с того же сервера, что и тот, на котором размещено приложение. Менеджер транзакций может использовать отдельный координатор транзакций для управления процессом фиксации / отката. Они могут обмениваться данными с использованием протокола, такого как TX. . В других случаях диспетчер транзакций может передавать инструкции фиксации / отката непосредственно диспетчеру ресурсов (базе данных), используя такой протокол, как XA. Таким образом, Функции координации и управления транзакциями до некоторой степени разделены и могут выполняться или не выполняться одним и тем же программным обеспечением. В случае MSDTC они разделены, но это не является строго обязательным.

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