A database configuration change has helped resolve two significant concurrency problems in a Mojaloop deployment: incoming transfers being blocked during settlement-window closure and a long-standing deadlock involving the central-ledger timeout handler.
The change is straightforward: move MySQL’s default transaction isolation level from REPEATABLE READ to READ COMMITTED.
But changing a database isolation level is not something to do without understanding the implications. For teams operating Mojaloop in production, the important questions are why this change helps, whether it is appropriate for their deployment, and how to introduce it safely.
A new article from Mojaloop core team member Shashikanth Hirugade examines those questions and recommends READ COMMITTED as Mojaloop’s default MySQL isolation level.
What the Article Will Help You Understand
If you operate or support a Mojaloop-based instant payment system, the paper provides a practical look at:
- Why REPEATABLE READ can create contention in Mojaloop’s central-ledger and settlement processes.
- How gap locks and next-key locks contribute to settlement delays and timeout-handler deadlocks.
- Why READ COMMITTED is a better fit for Mojaloop’s hot-path transactions.
- What to check before changing the isolation level, including transaction behavior, replication configuration and application-level overrides.
- How to test the change without making it permanent.
- How to make READ COMMITTED persistent across MySQL restarts and Kubernetes redeployments.
- What to monitor after the change, including deadlocks, lock waits and long-running transactions.
- How to roll the change back if your deployment reveals an unexpected dependency on REPEATABLE READ semantics.
A Change that Can Be Tested and Reversed
Adopters can evaluate READ COMMITTED without waiting for a future Mojaloop release. The paper provides steps for testing the change, making it persistent and incorporating it into the MySQL server configuration, including an important consideration for Kubernetes deployments where the database data directory may be ephemeral.
The change is reversible, but deployments should first verify that no application code relies on repeatable snapshots within a transaction, replication is not using statement-based binary logging, and application code does not explicitly set the isolation level for individual connections.
A Practical Recommendation for Mojaloop Adopters
The investigation produced a concrete result: after switching to READ COMMITTED, the timeout-handler deadlock did not recur, and settlement-window closure no longer visibly stalled incoming transfer throughput.
For teams running Mojaloop in production, this makes the article worth reading — particularly if you have experienced deadlocks, lock waits or changes in transfer latency around settlement processing.
