What is two-phase commit (2PC/XA) and why Sagas are preferred

Phase 1: PREPARE (Voting)
  Coordinator -> Participant A: "Prepare to commit transfer"
  Coordinator -> Participant B: "Prepare to commit transfer"

  Participant A: locks rows, stages changes, votes YES
  Participant B: locks rows, stages changes, votes YES

  Both now HOLD LOCKS and wait for Phase 2.

Phase 2: COMMIT (Decision)
  Coordinator: all voted YES -> writes COMMIT decision to log
  Coordinator -> Participant A: "COMMIT"
  Coordinator -> Participant B: "COMMIT"

  Both commit and release locks.

package com.bank.twopc;

import java.util.logging.Logger;

public class TwoPhaseCommitDemo {

    private static final Logger LOG = Logger.getLogger(TwoPhaseCommitDemo.class.getName());

    public void simulateCoordinatorCrash() {
        // Phase 1: Both participants vote YES, hold locks
        LOG.info("Participant A: voted YES, holding lock on SAV2001");
        LOG.info("Participant B: voted YES, holding lock on SAV2002");

        // Coordinator crashes here.
        LOG.severe("COORDINATOR CRASHED after unanimous YES");

        // Participants cannot safely decide:
        //   Commit? Maybe coordinator decided to abort.
        //   Abort? Maybe coordinator decided to commit.
        //   Wait? Locks held indefinitely. Other transfers blocked.
        LOG.warning("SAV2001 locked indefinitely. All transfers to/from blocked.");
        LOG.warning("SAV2002 locked indefinitely. All transfers to/from blocked.");
    }
}

Coordinator crash timeline:
  T=0: Prepare -> both vote YES, locks held
  T=1: Coordinator crashes
  T=2: Participants stuck. Cannot commit or abort safely.
  T=?: Coordinator recovers -> broadcasts decision -> locks released.
  Until then: rows locked, all other transfers blocked.

Problem 1: Synchronous and chatty.
  Multiple network round trips: prepare, vote, decide, commit.
  Latency adds up. Throughput is low.

Problem 2: Availability coupled to weakest link.
  If any participant or coordinator is down, the whole tx stalls.
  Opposite of fault isolation that microservices aim for.

Problem 3: Requires XA-capable interfaces.
  REST services: not XA-capable.
  Most NoSQL stores: not XA-capable.
  Kafka (typical use): not XA-capable.
  Only relational databases and JMS brokers support XA.

Problem 4: Locks held across the network.
  In a high-throughput bank, rows locked for seconds or minutes
  cause cascading timeouts and effectively take the system down.

package com.bank.saga;

import org.springframework.stereotype.Service;
import java.math.BigDecimal;
import java.util.logging.Logger;

@Service
public class TransferSaga {

    private static final Logger LOG = Logger.getLogger(TransferSaga.class.getName());
    private final AccountClient accountClient;

    public TransferSaga(AccountClient accountClient) {
        this.accountClient = accountClient;
    }

    public void execute(String fromId, String toId, BigDecimal amount) {
        try {
            // Step 1: local tx in Account Service, commits immediately
            accountClient.debit(fromId, amount);
            LOG.info("Saga step 1: debited " + fromId + " (lock released)");

            // Step 2: local tx in Account Service, commits immediately
            accountClient.credit(toId, amount);
            LOG.info("Saga step 2: credited " + toId + " (lock released)");

        } catch (Exception e) {
            // Compensating action: reverse step 1
            accountClient.credit(fromId, amount);
            LOG.warning("Saga compensated: re-credited " + fromId);
        }
    }
}

2PC: debit + credit locked together until coordinator decides.
  Locks held across network. Coordinator crash = stuck.

Saga: debit commits immediately (lock released), then credit commits.
  No coordinator. No held locks. Compensation on failure.
  Eventual consistency: brief window where money is "in flight."

2PC is appropriate:
  - Two databases under one service (e.g., primary + audit DB)
  - One database + one JMS broker under one operator
  - Scale is modest, latency tolerance is high
  - Atomicity is non-negotiable and both resources support XA

2PC is NOT appropriate:
  - Cross-service operations over REST/gRPC
  - Kafka-based event-driven workflows
  - High-throughput, low-latency banking transfers
  - Services not under the same operator

package com.bank.antipattern;

// WRONG: 2PC across REST services.
// REST is not XA-capable. This does not work.
public class Wrong2pcAcrossServices {
    // transactionManager.begin()
    // accountServiceRest.debit()    <- no XA
    // paymentServiceRest.credit()   <- no XA
    // transactionManager.commit()   <- cannot coordinate non-XA resources
}

// CORRECT: Saga with compensating actions.
public class CorrectSagaApproach {
    // accountClient.debit()  -> commits locally, lock released
    // accountClient.credit() -> commits locally, lock released
    // On failure -> accountClient.credit(fromId) -> compensate
}

  2PC vs Saga Timeline:

  2PC:
  T=0  Coordinator: PREPARE
  T=1  Participants: vote YES, HOLD LOCKS
  T=2  Coordinator: COMMIT (or crashes -> locks held)
  T=3  Participants: commit, release locks
  Locks held: T=1 to T=3 (or indefinitely on crash)

  Saga:
  T=0  Step 1: Debit SAV2001 -> commit -> LOCK RELEASED
  T=1  Step 2: Credit SAV2002 -> commit -> LOCK RELEASED
  On failure:
  T=2  Compensation: Credit SAV2001 -> money returned
  Locks held: only during each individual commit (milliseconds)