Example
Your accounting system stores invoices in its database. Suppose you want to do triple-entry accounting by publishing your invoices also to the blockchain so you have a copy in the distributed ledger. What can you do to make this reliable?
The Problem
It turns out it's not trivial to update both systems in one go. The intuitive approaches many developers would use do not work. To see why, let's try:
Attempt 1: Commit in DBMS, then push to the blockchain
In this approach, one would:
- Update and commit the local DBMS
- If this worked, then push to the blockchain
If there is a crash between 1 and 2 then you will have a DBMS update, but no blockchain publication.
Attempt 2: Push to blockchain, then update / commit in DBMS
Here we go:
- Push to the blockchain
- If this worked, then update / commit the DBMS
If there is a crash in between 1 and 2 then you will have published in the blockchain, but without DBMS update.
The Solution

Use JTA/XA transactions and a message queue to create an atomic transaction:
- Create a JTA transaction
- Update your XA-capable DBMS
- Post a message to an XA-capable queue requesting a blockchain publication
- Commit the JTA transaction
The key point is that the success of 2 and 3 coincide with the commit of 4. If there is no commit, then none of 2 or 3 will happen.
Then have a background component that:
- Reads a message from the queue
- Publishes in the blockchain accordingly
- If this worked, remove the message from the queue
If there is a failure / crash between 1 and 2 then the publication can be retried later. If there is a crash between 2 and 3 then the publication may be attempted twice. Either the code detects this (and does nothing the second time), or the logic that reads data from the blockchain ignores duplicate entries. We are assuming either one of these is possible and feasible.