To Vote Before Decide: A Logless One-Phase Commit Protocol for Highly-Available Datastores

Highly-available datastores are widely deployed for online applications. However, many online applications are not contented with the simple data access interface currently provided by highly-available datastores. Distributed transaction support is demanded by applications such as large-scale online payment used by Alipay or Paypal. Current solutions to distributed transaction can spend more than half of the whole transaction processing time in distributed commit. An efficient atomic commit protocol is highly desirable. This paper presents the HACommit protocol, a logless one-phase commit protocol for highly-available systems. HACommit has transaction participants vote for a commit before the client decides to commit or abort the transaction; in comparison, the state-of-the-art practice for distributed commit is to have the client decide before participants vote. The change enables the removal of both the participant logging and the coordinator logging steps in the distributed commit process; it also makes possible that, after the client initiates the transaction commit, the transaction data is visible to other transactions within one communication roundtrip time (i.e., one phase). In the evaluation with extensive experiments, HACommit outperforms recent atomic commit solutions for highly-available datastores under different workloads. In the best case, HACommit can commit in one fifth of the time 2PC does.

💡 Research Summary

The paper introduces HACommit, a log‑less one‑phase atomic commit protocol designed for highly‑available distributed datastores. Traditional distributed commit mechanisms—most notably two‑phase commit (2PC) and many recent non‑blocking variants—follow a “vote‑after‑decide” pattern: the client first decides to commit or abort, then asks participants to vote. This approach inevitably requires at least two communication round‑trips and persistent logging (or log replication) on both coordinator and participants, which can dominate the overall transaction latency, especially in geo‑distributed environments.

HACommit flips this paradigm to a “vote‑before‑decide” approach. While processing the last operation of a transaction, each participant locally checks consistency, isolation, and integrity constraints, then immediately votes YES or NO on whether the transaction can be committed. The vote, together with a compact transaction context (key‑value set, version information, isolation level, etc.), is replicated to the participant’s replicas. No separate write‑ahead log is created; the replicated vote serves the same recovery purpose as a log entry.

After gathering votes from all participants, the client proposes the final decision (commit or abort) to the participants. HACommit runs the Paxos consensus algorithm exactly once for each transaction outcome. The client acts as the initial proposer, which allows the protocol to skip the Paxos “prepare” phase and perform only the “accept” phase. Once a majority of replicas from any participant accept the client’s proposal, the transaction is considered decided. Because the decision is disseminated in the same round‑trip that carries the client’s proposal, the transaction’s effects become visible to other transactions after a single communication round‑trip—effectively a one‑phase commit.

The protocol addresses two major challenges:

1. Correct one‑phase commit/abort – By mapping the commit decision to a Paxos value, HACommit guarantees that all correct participants reach the same outcome even if the client crashes after sending the proposal. The consensus guarantees safety (no divergent outcomes) and liveness (eventual decision) under asynchronous networks with crash failures.

2. Failure recovery without logs – HACommit leverages the inherent data replication of highly‑available stores. Participants replicate their votes and transaction metadata to their replicas as part of normal operation. If a participant fails, any surviving replica that holds the replicated vote can continue the protocol. If the client fails, the remaining participants can become new proposers and re‑run Paxos to reach the same decision, ensuring non‑blocking behavior.

HACommit is compatible with a wide range of concurrency control schemes (optimistic, multi‑version, lock‑based) and isolation levels (read‑committed, serializable). The only requirement is that the last operation be identifiable so that participants can trigger the vote‑before‑decide step.

Evaluation – The authors implemented HACommit and compared it against several recent commit protocols (Spanner, MDCC, TAPIR, Helios, Message Futures) using a YCSB‑based transaction benchmark. They varied the number of participants, the number of operations per transaction, and the size of the data set. Key findings include:

• HACommit consistently achieves commit latencies under 1 ms, roughly one‑fifth of the latency observed for classic 2PC under the same conditions.
• The protocol’s latency is insensitive to the number of operations per transaction because the voting phase overlaps with the processing of the last operation, eliminating an extra round‑trip.
• In the presence of client crashes, HACommit remains non‑blocking; the remaining participants successfully complete Paxos and finalize the transaction.
• Participant replica failures are handled by the replicated votes; as long as a quorum of replicas survives, the transaction can be recovered without any log replay.

Implications – By eliminating logging and reducing the commit to a single network round‑trip, HACommit dramatically improves throughput and latency for workloads that require strong ACID guarantees on top of highly‑available storage. This makes it especially attractive for large‑scale online payment platforms (e.g., Alipay, PayPal), real‑time analytics, and any service where both high availability and fast, atomic transaction processing are mandatory.

In summary, HACommit demonstrates that, when a datastore already provides high data availability through replication, the traditional reliance on persistent logs for atomic commit can be removed. Leveraging Paxos for consensus, replicating votes, and adopting a vote‑before‑decide workflow yields a practical, non‑blocking, one‑phase commit protocol that outperforms existing solutions both in latency and simplicity.