# Eliminating Cross-Database Split-Brain by Construction — arXiv submission package

Author: yxpil
Artifact: the framework under study lives in the author's local repository;
this package is self-contained and carries its own measured artifacts.

## Title

**Eliminating Cross-Database Split-Brain by Construction: Pre-Freeze Coordination with Node-Autonomous Recovery**

## Suggested arXiv classification

- Primary: `cs.DC` (Distributed, Parallel, and Cluster Computing)
- Cross-lists: `cs.DB` (Databases), `cs.SE` (Software Engineering)

`cs.DC` is the best primary fit: the subject is a cross-resource coordination
protocol and the failure mode it removes (split-brain across independent
databases) is a distributed-systems failure. `cs.DB` is the natural
cross-list because the participants are databases and the paper's protocol is
expressed directly in terms of local transactions, freeze markers and
per-shard key ranges. `cs.SE` works as a third cross-list if the reviewer is
interested in the artifact-as-teaching-vehicle framing.

## Abstract (verbatim)

> Cross-database split-brain is normally treated as a protocol problem: to stop
> two independently deployed databases from disagreeing about a shared outcome,
> one adds a consensus group, a quorum rule, or an external arbiter. We take
> the opposite route and eliminate the failure class instead of defending
> against it. The business-asset databases in our design never exchange a
> message with one another, each performs only single-node local transactions
> with its own local replication, and every cross-database decision is taken by
> a stateless business-layer coordinator. The coordinator reserves (freezes)
> each participant's local assets before any real value moves, records the
> global transaction in a guarded state machine, and compensates along an
> explicit per-operation phase model, so that a compensation can never be
> applied in the wrong direction. Recovery is layered: a poller and a
> dead-letter handler resume transactions when a participant is unreachable,
> verifying the real asset state before deciding whether to move forward or
> compensate, and a second layer lets a recovered node inspect its own local
> freeze markers and settle its own debt autonomously when the coordinator
> cannot reach it. We implement the design as an executable teaching artifact:
> three operating-system processes stand in for three databases, JSON files
> stand in for shards and replicas, and seven scripted fault cases exercise
> normal ordering, freeze rejection, mid-commit failure, shard partition and
> recovery, node crash and restart, orphan-freeze reconciliation, and retry
> exhaustion. All seven cases pass; we report the measured transcript, the
> per-case wall-clock durations, and the coordinator's protocol traffic. The
> artifact is not a production system. We state the six gaps that separate it
> from production, the trade-offs it accepts (eventual rather than serializable
> consistency, write amplification, a new critical component, and a freeze TTL
> that must be tuned to the real recovery-time distribution), and the kinds of
> system for which we believe a simpler mechanism should be preferred.

## Abstract for the arXiv form (1,920-character limit)

The abstract printed in the paper is longer than the form accepts; paste this
version into the arXiv metadata field instead. It keeps every measured number
and drops only prose.

> Cross-database split-brain is normally treated as a protocol problem: to
> stop two databases from disagreeing about a shared outcome, one adds a
> consensus group, a quorum, or an external arbiter. We take the opposite
> route and eliminate the failure class instead of defending against it. The
> business-asset databases in our design never exchange a message, each
> performs only single-node local transactions with its own local replication,
> and every cross-database decision is taken by a stateless business-layer
> coordinator. The coordinator freezes each participant's local assets before
> any real value moves, records the global transaction in a guarded state
> machine, and compensates along an explicit per-operation phase model, so a
> compensation can never be applied in the wrong direction. Recovery is
> layered: a poller and a dead-letter handler resume transactions when a
> participant is unreachable, verifying real asset state before deciding
> whether to move forward or compensate, and a recovered node can inspect its
> own freeze markers and settle its own debt when the coordinator cannot reach
> it. We implement the design as an executable teaching artifact: three OS
> processes stand in for three databases, JSON files for shards and replicas,
> and seven scripted fault cases exercise normal ordering, freeze
> rejection, mid-commit failure, shard partition and recovery, node crash and
> restart, orphan-freeze reconciliation, and retry exhaustion. All seven pass;
> we report the transcript, wall-clock durations and the coordinator's
> protocol traffic. The artifact is not a production system: we state the six
> gaps that separate it from production, the trade-offs it accepts (eventual
> rather than serializable consistency, write amplification, a freeze TTL
> tuned to the recovery-time distribution), and the systems for which a
> simpler mechanism should be preferred.

## Files

```
main.tex                 the paper
refs.bib                 bibliography
common.tex               shared preamble (copied in at packaging time)
figures/
  fig_architecture.pdf   system context: three databases, coordinator, state store
  fig_state_machine.pdf  global transaction state machine and its guards
  fig_self_healing.pdf  the two recovery layers and who may settle what
  fig_case_durations.pdf per-case wall-clock duration, measured
results/
  summary.json           terminal state and transition count per case
  case_timings.csv       wall-clock duration per case
  protocol_traffic.csv   coordinator round-trips and logical store writes
  protocol_traffic.json  the same, machine-readable
  transcript.txt         raw transcript of a real run
  transcript_sanitized.txt  the English transcript quoted in the paper
  preview/*.png          rasterised previews of the four figures
scripts/
  run_cases_timed.py     re-run the seven cases and time them
  count_protocol_traffic.py  measure coordinator traffic and write amplification
  sanitize_transcript.py    produce the English transcript from a real run
  sync_listing.py        copy the measured transcript into main.tex verbatim
  make_figures.py        regenerate the four PDF figures (no third-party deps)
  preview_figures.py     layout verification for the generated figures
  check_paper.py         static sanity check of main.tex (brace/label/cite)
```

## Build

```bash
cd papers/dtxn-freeze
cp ../_shared/common.tex common.tex

pdflatex main
bibtex main
pdflatex main
pdflatex main
```

or, with `tectonic` (fetches packages on demand, runs bibtex automatically):

```bash
tectonic -X compile main.tex --keep-logs
```

Note that `main.tex` loads `natbib` *after* `\input{common.tex}`, because the
`abbrvnat` bibliography style requires it and `common.tex` ends with
`hyperref`. The natbib manual states the relative load order of `natbib` and
`hyperref` is not significant, so this ordering is safe.

## Package for arXiv

```bash
bash papers/make_package.sh dtxn-freeze
```

This produces `papers/dist/dtxn-freeze.tar.gz` containing `main.tex`,
`common.tex`, `refs.bib`, `figures/`, `results/`, and `scripts/`.

## Submit

1. Go to <https://arxiv.org/abs/cs.DC> and click **Submit new paper**.
2. Upload `papers/dist/dtxn-freeze.tar.gz`.
3. Category: `cs.DC` primary; add `cs.DB` and `cs.SE` as cross-lists.
4. Copy the abstract above into the metadata form.
5. License: the arXiv perpetual non-exclusive license is fine.
6. **Author identity.** The author block in `main.tex` currently reads
   *yxpil*, Undergraduate student, School of Software Engineering, Yunnan
   Technology and Business University, China. arXiv requires the listed name
   to match the account holder. If you want the byline to read *Daozhendong
   Yang* instead of the pen name, change `\author{...}` in `main.tex`
   **before** packaging, and use the same name on the arXiv account.

## Reproducing the numbers

```bash
cd papers/dtxn-freeze

# re-run the seven fault cases and re-measure their durations
python scripts/run_cases_timed.py

# measure the coordinator's protocol traffic and write amplification
python scripts/count_protocol_traffic.py

# regenerate the English transcript from a fresh run
python scripts/sanitize_transcript.py

# keep the quoted listing byte-identical to the measured transcript
python scripts/sync_listing.py

# regenerate the four figures (pure standard library, writes vector PDF)
python scripts/make_figures.py

# check main.tex without a TeX installation
python scripts/check_paper.py
```

Every number in the evaluation section comes from `results/`, and those files
are regenerated by the scripts above. `scripts/sync_listing.py` exists
specifically so that the transcript quoted in the paper cannot drift away
from the transcript a reader would obtain by re-running the artifact.

## What the paper does not claim

Read this before submitting; it is the same list the paper's Limitations
section carries, and it is deliberately blunt.

- **The artifact is a simulation.** Three OS processes stand in for three
  databases and JSON files stand in for shards and replicas. The file store
  simulates row locks; it does not have a real database's concurrency or
  durability behaviour.
- **Not production-ready.** The paper enumerates six specific gaps between
  the artifact and a deployable system, including single-process polling
  without leader election, a dead-letter queue that is a method call rather
  than a real broker, no optimistic-locking between the poller and a node's
  startup self-check, and reconciliation that is scheduled rather than
  event-driven.
- **Eventual consistency, not serializability.** Between the freeze and the
  final commit there is a visible intermediate state. This design is
  unsuitable for accounting-grade strong consistency.
- **The coordinator is a new critical component.** Moving the split-brain
  risk into the coordinator's availability and throughput does not remove it.
- **The freeze TTL is a tuning parameter, not a constant.** It must be
  derived from the real recovery-time distribution of the slowest shard.
- **Residual risk.** If the global transaction record store is destroyed with
  no valid backup, orphaned reservations can exist; offline reconciliation is
  what detects them.
- **Where a simpler mechanism wins.** The paper states plainly which systems
  should not use this design: anything a single-database transaction can
  solve, and anything that requires serializable consistency.