Ecco come si può teoricamente gestire questa situazione. Per prima cosa è necessario disporre di più gestori di transazioni distribuite JTA su ciascun nodo. Uno agisce come il padrone, l'altro come schiavo. Il master coordina il commit/rollback della transazione distribuita agli slave. Esistono implementazioni JTA stand alone, ad es. JOTM.
Vanilla RMI non supporta la propagazione delle informazioni di contesto come l'ID della transazione dell'operazione. Ma penso che RMI abbia dei ganci in modo che possa essere esteso per supportarlo. Puoi dare un'occhiata a Carol.
È necessario utilizzare XAResource per includere i partecipanti nella transazione in modo che possano essere inclusi nella transazione distribuita. Il master dovrà inviare messaggi di commit/rollback agli slave, che dovranno utilizzare XATerminator per agire di conseguenza.
La specifica JTA è solo una transazione distribuita manager, la registrazione delle operazioni in un log delle transazioni deve essere eseguita dai server. La libreria esiste per la gestione del log delle transazioni, ad es. HOWL.
Non penso che Spring possa essere utilizzato, anche con un gestore di transazioni distribuito, per farlo facilmente. Ho provato una volta a utilizzare RMI con transazione distribuita controllata da un client standalone e diversi slave. Ecco uno blog post su di esso. Era piuttosto complicato.
È possibile ottenere tutto ciò gratuitamente se si utilizza un server di applicazioni Java EE, con IIOP. IIOP supporta la propagazione delle transazioni distribuite. Il client può essere un application client container ed è possibile controllare le transazioni con UserTransaction. Questo è in realtà uno dei rari casi, in cui penso che l'utilizzo di un server delle applicazioni sia davvero giustificato.
Ma ciò detto, le transazioni distribuite sono cose complicate, che possono portare a errori euristici, timeout se un nodo muore e complicate procedure di ripristino.
Il mio ultimo consiglio sarebbe quindi: provare a trovare un disegno che non implichi transazioni distribuite se possibile. Questo ti renderà molto più facile.
È possibile trarre ispirazione da BPEL compensation mechanism. Esistono forse altri approcci progettuali per la gestione degli errori e la robustezza che possono evitare le transazioni distribuite di utilizzo.
Grazie per aver trovato il tempo di rispondere così in profondità. –