Basically relying on distributed ACID-Transaction in the SOA world isn't a good idea at all. Basically this is the "power" of the whole concept: If you make it asynchronous, you have to think of solving these kind of problems differently, not with technical transactions (like compensating actions, ...), which makes the whole architecture more open for later changes.
But anyway, if you change to InVM transport it should be possible to span a Java-Transaction over multiple service calls and using a single rollback. But please be aware, that this is not really "the SOA way" and it has downsides in the terms of architecture...
Cheerio and merry christmas
Thanks, Bernd, for your answer!
I will take your advice. This will need to try to work with InVM courier.
you have to think of solving these kind of problems differently, not with technical transactions (like compensating actions, ...)
It`s good idea too. But we need to make a lot of data changes in one or more databases in different ESB services, and all changes must be in a single distributed transaction.
Okay, just wanted to make the remark, you should be open to look for different possibilities to get around the technical transactions if you want to arrive in the SOA world ;-)
Thank you, Bernd.