Вот как теоретически можно справиться с этой ситуацией.Во-первых, вам нужно иметь несколько распределенных диспетчеров транзакций JTA на каждом узлеОдин действует как хозяин, другой - как раб.Ведущий координирует фиксацию / откат распределенной транзакции для подчиненных.Существуют автономные реализации JTA, например, JOTM .
Vanilla RMI не поддерживает распространение контекстной информации, такой как идентификатор транзакции операции.Но я думаю, что RMI имеет хуки, так что он может быть расширен для поддержки этого.Вы можете взглянуть на Кэрол .
. Вам нужно будет использовать XAResource , чтобы обернуть участников транзакции, чтобы они могли быть зачислены в распределенную транзакцию.Мастер должен будет отправлять сообщения подтверждения / отката на подчиненные устройства, которые должны будут использовать XATerminator , чтобы действовать соответственно.
Спецификация JTA представляет собой только распределенную транзакцию менеджер , регистрация операций в журнале транзакций должна выполняться серверами.Существует библиотека для управления журналом транзакций, например, HOWL .
Я не думаю, что Spring можно использовать - даже с распределенным менеджером транзакций - для этого легко.Я однажды пытался использовать RMI с распределенной транзакцией, управляемой от отдельного клиента и нескольких ведомых устройств.Вот сообщение в блоге об этом.Это было довольно сложно.
Вы можете получить все это бесплатно, если используете сервер приложений Java EE с IIOP.IIOP поддерживает распространение распределенных транзакций.Клиент может быть клиентским контейнером приложения , и вы можете контролировать транзакции с помощью UserTransaction .На самом деле это один из редких случаев, когда я думаю, что использование сервера приложений действительно оправдано.
Но при этом распределенные транзакции - это сложные вещи, которые могут привести к эвристическим сбоям, тайм-ауту, если один узел умирает, и сложнымпроцедуры восстановления.
Тогда мой последний совет: попытайтесь найти проект, который не включает распределенную транзакцию, если это возможно.Это сделает вашу жизнь намного проще.
Вы можете черпать вдохновение в BPEL механизм компенсации .Возможно, существуют другие подходы к проектированию для обработки ошибок и надежности, которые могут избежать использования распределенных транзакций.