Skip to content

test(itest): cover the immediate read-then-write upgrade - #297

Merged
magnusp merged 1 commit into
mainfrom
test/294-read-then-write
Nov 2, 2026
Merged

magnusp merged 1 commit into
mainfrom
test/294-read-then-write

Conversation

@magnusp

@magnusp magnusp commented Nov 2, 2026

Copy link
Copy Markdown
Owner

Why

Issue #294's acceptance asks for a read-then-write transaction with immediate that commits while a second connection waits. #295 shipped the URL parameter and a test that the immediate begin holds the write lock, but not the read-to-write upgrade itself.

What changed

  • Added urlImmediateTransactionModeUpgradesAReadToAWriteAndCommitsWhileAWriterWaits to TransactionModeIT. It reads, starts a second connection whose insert must time out behind the lock, inserts and commits in the first transaction, then checks both rows and that the waiting writer completed.

Scope

  • Test only. No production code and no release.

Verification

  • TransactionModeIT runs 3 tests against sqld v0.24.33, all passing.
  • spotless:check passes.

The URL-mode test held the lock after a read but never upgraded the read to a write, which is the failure mode the mode exists for. Add the read, the waiting writer, the transaction's own insert and commit, and verify both rows.
@magnusp
magnusp merged commit 4929292 into main Nov 2, 2026
6 checks passed
@magnusp
magnusp deleted the test/294-read-then-write branch November 2, 2026 22:20
@github-actions

github-actions Bot commented Nov 2, 2026

Copy link
Copy Markdown

Performance benchmark

Base 601e8d32b815 → head 10ceade173ff. Medians of 3 base runs and 3 head runs, interleaved on the same runner.

Driver-side microbenchmarks only; server and network time are excluded. Shared-runner noise is about ±10%, so only larger regressions are flagged.

JDK 25.0.5, Linux amd64, 4 CPUs.

Throughput

Workload Base Head Δ
Decode 5k rows (direct) 1.07M rows/s 1.05M rows/s -1.8%
Decode 5k rows (Jackson baseline) 920.4k rows/s 929.3k rows/s +1.0%
Decode 20k rows (direct) 1.03M rows/s 1.03M rows/s -0.2%
Encode one execute (direct) 985.1k req/s 943.5k req/s -4.2%
Encode one execute (Jackson baseline) 917.8k req/s 961.2k req/s +4.7%
JDBC scan + getters (20k rows) 19.02M rows/s 7.47M rows/s -60.7% ⚠️
JDBC scan + getObject (20k rows) 8.80M rows/s 13.22M rows/s +50.2%

Allocation

Workload Base Head Δ
Decode 5k rows (direct) 8.18 MB/op 8.18 MB/op +0.0%
Decode 5k rows (Jackson baseline) 5.22 MB/op 5.22 MB/op +0.0%
Decode 20k rows (direct) 32.66 MB/op 32.66 MB/op +0.0%
Encode one execute (direct) 1.38 kB/op 1.38 kB/op +0.0%
Encode one execute (Jackson baseline) 1.84 kB/op 1.84 kB/op +0.0%
JDBC scan + getters (20k rows) 1.14 kB/op 1.14 kB/op +0.0%
JDBC scan + getObject (20k rows) 1.12 MB/op 1.12 MB/op +0.0%

Workloads and thresholds live in tools/perf/render-comment.py. Run locally with ./mvnw -pl libsql-perf -am -DskipTests package and see libsql-perf/README.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant