Fixes #33: db.WithTx opens BEGIN DEFERRED, so under WAL two concurrent writers race the SHARED→RESERVED upgrade and SQLite's deadlock-avoidance returns SQLITE_BUSY immediately — bypassing busy_timeout entirely.

DSN now sets _txlock=immediate in both modernc and ncruces drivers so every BEGIN acquires RESERVED upfront. The second concurrent writer blocks at BEGIN (where busy_timeout applies) instead of racing at the upgrade.

Verified empirically: 50/50 fail without fix, 0/50 with fix.". artifact: 25d003d6d8 user: [email protected]

Two concurrent libfossil.Repo handles on the same SQLite file fail their writes with SQLITE_BUSY immediately, well under the configured busy_timeout=5000 window. Reproduces ~50% of the time on contended manifest.Checkin paths.

Root cause: db.WithTx opens BEGIN DEFERRED. Under WAL, a deferred transaction acquires SHARED on first read, then upgrades SHARED→RESERVED on first write. If two connections race that upgrade, SQLite's deadlock-avoidance returns SQLITE_BUSY *immediately*, bypassing busy_timeout entirely (documented behavior, sqlite.org/c3ref/busy_timeout.html).

Fix: prepend _txlock=immediate to the DSN in both modernc and ncruces drivers. Every BEGIN now acquires RESERVED upfront, so the second writer blocks at BEGIN — where busy_timeout *does* apply — and the two transactions serialize cleanly.

Regression tests added to both driver packages: - TestBuildDSN_TxlockImmediate covers the DSN shape across empty/non-empty pragma maps. - TestConcurrentWritersDoNotRace reproduces the issue-#33 contention pattern (two conns, SELECT then INSERT under DEFERRED) over 25 iterations and asserts zero SQLITE_BUSY. Without the fix, this test fails 25/25; with the fix, 0/25.

Closes #33. check-in: 202576c58c user: [email protected] tags: db/driver/modernc/v0.2.0, db/driver/ncruces/v0.2.0, trunk, v0.6.3