рекомендации по написанию нового менеджера транзакций с пользовательской логикой фиксации / отката

Question

Я хотел бы написать менеджер транзакций, который бы поддерживал логику коммитов multi-db и best force commit.Должен ли я создать его из Spring AbstractPlatformTransactionManager или javax.transaction.TransactionManager или чего-то еще?

У меня есть существующие приложения, которые используют Spring's JpaTransactionManager и DataSourceTransactionManager и внутренний настраиваемый CustomTransactionManager,

Моя цель - предоставить единый менеджер транзакций для всех моих Java-приложений, чтобы я мог предлагать / контролировать общие функции транзакций.Мое требование не 2PC, но мне нужна поддержка нескольких источников данных с максимальным усилием фиксации (диспетчер транзакций уведомляет приложение о сбоях фиксации, и на него возлагается обязанность обрабатывать ситуацию, повторяя неудачные запросы).

Я читал оSpring 101 *, его реализации Jpa и Datasource Transaction manager.Проверенная реализация JTA / XA, предоставленная в SimpleJta , которая основана на классах пакетов javax.transaction.xa.

Когда я рассматриваю требование простой интеграции с существующими приложениями, AbstractPlatformTransactionManager Spring выглядит какхороший базовый класс для нового менеджера транзакций.С другой стороны, пакет javax.transaction.xa предоставляет несколько простых абстракций для управления ресурсами соединения в транзакции.Может быть, если я смогу реализовать однофазную фиксацию с javax.transaction, она будет работать.

Мой вопрос таков: лучше использовать AbstractPlatformTransactionManager Spring Framework или использовать javax.transaction и интегрировать его с приложениями Spring будетбудь хорошим?

Я рассчитываю написать легко интегрируемый (с существующими весенними приложениями) простой и обслуживаемый компонент.

Извинения, если вопрос слишком расплывчат.Я все еще читаю варианты, и у меня может не быть полного понимания весны и javax.transaction.

Answer 1

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

Есть веские причины, почему это не обычное дело. Вы, вероятно, не должны пытаться сделать это Вещью, пока не поймете, что это такое.

Если вам нужны гарантии, что транзакции вашего приложения восстановятся после сбоя, включая сбой сервера, тогда Full XA - ваш единственный выбор.

Это ... неправильно. Это правда, что вам нужны полные ACID гарантии, тогда XA в значительной степени ваш единственный выбор для совместимой передачи данных с участием баз данных. Однако, например, WS-AT - превосходный протокол транзакций ACID для веб-менеджеров ресурсов.

ACID транзакции - это еще не все. Для транзакций сагового типа вам нужна какая-то форма компенсации, которая обеспечивает обратные вызовы жизненного цикла приложения. WS-BA и более поздние микропрофильные спецификации LRA работают в этой области.

Итак, ваш выбор примерно таков: (неправильно) использовать XA, например, оптимизация фиксации последнего ресурса, многократные последние ресурсы или другие ослабленные гарантии и надежда на то, что JTA API достаточно гибок, или просто перейдите непосредственно к основанному на саге tx API, предназначенному для этой работы.

Я ожидаю написать ... простой и обслуживаемый компонент.

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

Narayana предоставляет полный ACID XA "из коробки", но может быть настроен для обеспечения максимальной эффективности в рамках API JTA, если вы действительно этого хотите. (Подсказка: нет). Также имеется поддержка саг через спецификации WS-BA и LRA, если вы предпочитаете идти по этому пути. Единственный заслуживающий доверия конкурент с сопоставимым набором функций вне полноценного сервера приложений JakaraEE - это Atomikos. Spring сам по себе НЕ является реализацией диспетчера распределенных транзакций, это API, который делегирует одному.

Answer 2

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

Если приложение поддерживает Spring, оно использует Spring JtaTransactionManager и Spring декларативное управление транзакциями, чтобы скрыть детали базовой синхронизации. Разница для разработчика между использованием XA и не использованием XA заключается в настройке фабричных ресурсов: экземпляров DataSource и менеджера транзакций для приложения. Экземпляры DataSource и менеджер транзакций являются единственными элементами приложения, специфичными для XA или JTA.

Пожалуйста, посмотрите этот художественный откат транзакции с несколькими источниками данных, это поможет вам лучше понять распределенную транзакцию Spring с и без XA (https://www.javaworld.com/article/2077963/distributed-transactions-in-spring--with-and-without-xa.html)