Нет, потому что это невозможно.
Давайте рассмотрим, для чего предназначен XA. Это согласованный протокол для гарантии свойств ACID для транзакций, охватывающих несколько менеджеров ресурсов. Для этого он использует протокол двухфазной фиксации: менеджер транзакций подготавливает каждого менеджера ресурсов, а затем фиксирует каждый из них.
Для правильной работы протокола менеджер ресурсов, например базы данных, должны предоставить определенные гарантии на этапе подготовки. К ним относятся: а) не делать какие-либо изменения видимыми для других процессов до фазы фиксации («Изоляция»), б) обеспечить возможность выполнения обновления во время фиксации, если это необходимо, даже если происходит сбой между подготовкой и фиксацией («Долговечность») и c) обеспечение того, чтобы данные, обрабатываемые в разных транзакциях, обладали обещанными свойствами согласованности. Реально единственный способ реализовать это - эксклюзивная блокировка. Даже менеджеры ресурсов, например pgsql и oracle, которые используют MVCC или другие методы во время большинства операций, при подготовке получат эксклюзивные блокировки.
Без доступа к внутренним компонентам БД вы не сможете получить блокировки и удерживать их через соединения. Следовательно, вы не можете написать код, который может соответствовать требованиям транзакций Таким образом, нет никакого наложения XA поверх ядра базы данных - его нужно запечь.
Однако ...
Вы можете подделать некоторые аспекты поведения XA. В зависимости от ваших конкретных требований к применению это может позволить создать полезное решение.
Прежде всего, вы можете использовать Last Resource Optimization (также называемый Last Resource Commit Optimization или Last Resource Gambit), чтобы включить один не-XA, то есть однофазный ресурс в транзакцию XA с одним или несколькими реальными ресурсами XA. Упорядочив однофазный ресурс, последний в порядке обработки, вы можете достичь чего-то, что ведет себя как XA для большинства сценариев. Он ужасно ломается, если в определенных точках выполнения происходит сбой, поэтому вы должны самостоятельно написать код согласования данных или положиться на человека, который бы справился с этой ситуацией. В зависимости от семантики ваших данных это может быть или не быть привлекательным вариантом.
Далее вы можете реализовать собственный драйвер, который работает так же, как семантическая репликация. Он записывает последовательность операций SQL в журнал во время подготовки, но фактически не применяет их к базе данных до фазы фиксации. Это работает для транзакционных обновлений, которые изолированы на уровне приложения, но не будут работать, если вы полагаетесь на db, чтобы выполнять контроль параллелизма за вас. Например, вы можете обнаружить, что фиксация не удалась, потому что что-то еще попало в конфликтующее обновление между фазами подготовки и фиксации. Вы можете использовать внешний менеджер блокировок, но только если ваш пользовательский драйвер - это единственное, что говорит с БД. Как только клиент, который не знает об этом менеджере блокировки, получает все ставки, он отключается.
Наконец, вы можете инвертировать эту модель и использовать транзакции на основе компенсации в XA. В этой модели вы применяете обновления во время подготовки и применяете дополнительные операции, чтобы при необходимости обратить их действие на этапе отката. Это имеет два недостатка: параллельные операции могут считывать и обрабатывать преждевременно зафиксированные значения tx, который впоследствии откатывается, поскольку между подготовкой и фиксацией нет изоляции; Кроме того, в зависимости от бизнес-логики не так просто сгенерировать подходящие компенсационные отчеты. Даже если вы можете, вам нужно довольно много сложных сантехнических работ, чтобы обеспечить их правильную работу даже в аварийных ситуациях.
Реально вы, вероятно, ограничены LRCO, который поддерживается "из коробки" большинством менеджеров транзакций. Другие варианты требуют значительного опыта в транзакциях, чтобы получить правильные результаты, и накладные расходы на разработку / тестирование обычно не оправданы. Если LRCO не будет работать для вас, то, честно говоря, будет проще изменить дизайн вашего приложения, чтобы избежать необходимости в XA.