When one business transaction touches multiple nodes, the key question is simple: how do you keep the operation atomic?
GBase Database (GBase 8c) uses distributed transaction coordination to ensure that a transaction spanning multiple participants either commits as a whole or rolls back as a whole.
How Two-Phase Commit Works
A simplified two-phase commit (2PC) flow looks like this:
Coordinator Participants (A, B)
|--- PREPARE ------------------>|
|<-- READY / ABORT -------------|
|--- COMMIT -------------------->|
Phase 1: Prepare
The coordinator asks each participating node to prepare the transaction.
Each participant validates the operation and persists the necessary transaction state. If all participants are ready, the transaction can move forward.
Phase 2: Commit
The coordinator sends the commit decision to the participants.
If any participant cannot prepare successfully, the transaction is rolled back instead of allowing a partial commit.
The core principle is:
All participants commit, or none of them do.
What Happens During Failures?
Distributed transactions become interesting when something fails between phases.
If the coordinator fails during commit, participants can use recovery mechanisms to determine the final transaction state. If a participant rejects the transaction during preparation, the global transaction is aborted.
This prevents applications from being left with a partially completed business operation.
For example, a financial ledger transfer should not debit one account successfully while failing to credit the other.
The Real Cost: Coordination
Distributed transactions introduce coordination overhead, so transaction design matters.
When only a small number of nodes participate, the additional coordination cost can often remain low. The bigger problem is a transaction that regularly spans many nodes.
That's why distribution-key design matters.
Instead of asking whether 2PC is "slow," ask:
Why does this transaction need to cross so many nodes?
Good distribution design keeps related data together and minimizes cross-node transaction boundaries.
When Should You Use Distributed Transactions?
Use distributed transactions when atomicity is a business requirement, such as:
- Financial transfers
- Inventory and order updates
- Multi-record business operations
- Consistency-critical workflows
For high-frequency append-only workloads that don't require cross-node atomicity, designing writes to stay within a single distribution boundary can reduce coordination overhead.
The Takeaway
Two-phase commit is not automatically a performance problem. Poor transaction and distribution design is often the bigger issue.
With GBase Database (GBase 8c), the practical rule is:
Keep atomic operations atomic, but design your data distribution so fewer transactions need to cross nodes.
How does your distributed database workload handle cross-node transactions: minimize them through data design, or rely heavily on distributed coordination?
