slipperyА кто будет координатором транзакций? если я определю 2 менеджера и повешу их на 1 метод, то просто первый откроет транзакцию свою, а второй свою. Оба будут вынимать свои сессии из локальных переменных потока и коммитить их, но не будут работать в единой цепочки как я понимаю. Для этого нужен третий(или возможно первый и единственный) который будет координировать действия создавать говорить, что нужно создать precommit, потом коммит, что будет являться этим координатором и как он настраивается? Если его реализация в спринге? Подойдет ли для работы с координатором org.springmodules.jcr.jackrabbit.LocalTransactionManager в jcr?

Прошу прощения если несу чушь, но в данной теме полный новичок.

Со спрингом и jackrabbit толком не работал, но склонен согласится.

Если в вашем environment есть обычный JTA TM, то можно заюзать jackrabbit как XA. У него есть модуль JCA (java connector architecture), он оборачивает АПИ jacrabbit в XA интерфейс.

JTA архитектура проста:

1. Вы настраиваете в app server'е неким server specific образом набор ресурсов. Типы ресурсов чётко ограниченные. Например есть sql DataSource. Для каждого указывается "драйвер" (какой-то класс, через который идёт работа). Драйвер имплементит определённый интерфейс (например, опять же DataSource).

2. Сервер bind'ит все эти ресурсы в JNDI.

3. Вы в JTA транзакции делаете lookup этих ресурсов. В этот момент он вешаются на текущую JTA транзакцию.

4. В момент commit/rollback JTA транзакции, TM сервера выполняет commit/rollback всех зарегистрированных на транзакцию ресурсов.

При этом:

1. TM можно настроить на XA режим, XA с LAO, 1PC режим. Всё это server specific образом, смотря ещё что поддерживает TM.

2. Тип каждого ресурса может быть 1PC, XA. Ресурс будет указанным образом пытаться регистрироваться в транзакции.

3. Если несостыковка (например, включён XA-LAO, а вы уже использовали в транзакции один 1PC ресурс и хотите использовать второй) - exception.

Вообще я ни разу не использовал JCA модули на практике. Я понимаю это дело так: JTA описывает лишь небольшой список конкретных ресурсов, которые могут участвовать в транзакции: EJB, JMS, JDBC, XA. Сервер должен предоставлять возможность дописать ему в дескрипторм такие модули. С JDBC, например, всё понятно, а вот XA ресурсы могут быть весь экзотические с неизвестными кастомными параметрами. Поэтому есть JCA, которая унифицирует их АПИ и формат дескрипторов, позволяя сказать серверу о наличии произвольных XA ресурсов.

Я так понимаю, что флоу по развёртыванию JCA модуля следующий:

1. Jacrabbit JCA модуль деплоится на сервер (наверное в спринг тоже как-то можно) - это просто .rar подложить в определённую папку, но там хитрый нейминг должен быть, надо смотреть туториалы.

2. Сервер bint'ит JCA ConnectionFactory в JNDI.

3. Вы в JTA транзакции делаете lookup этой ConnectionFactory. Далее делаете cf.createManagedConnection().getSession(), который в случае jacrabbit JCA должен возвращать javax.jcr.Session.

Собственно проще посмотреть сорс код JCA модуля, там совсем немного.

Вариант 2: если ваш JTA TM поддерживает LAO, то по идее достаточно, чтобы с базой работа шла через XA драйвер, а с jackrabbit через обычный.

Ещё есть хак, который может помочь разобраться с тем, как оно работает. Можно вручную делать TransactionManger.getTransaction().enlistResource(XAResource). Вручную добавляем произвольный XAResource в транзакцию.

Этот АПИ по идее предназначен для самих app server'ов, а клиентский код должен работать как я описал в предыдущем сообщении. Но для тестов можно просто попробовать любым способом получить из обычного jackrabbit API их XAResource и вручную воткнуть его в менеджер. Можно даже свой XAResource для их АПИ набросать. Если там всё будет нормально работать, то можно уже сесть поразбираться с тем, как деплоить их JCA модуль.