fix: make the TripleStore and TrustStateRegistry singletons thread-safe

[tkuhn]

Fixes a startup race condition, found while investigating why npa:thisRepo in the admin repo carries several npa:hasRepoInitId values: 2 on query.knowledgepixels.com, 5 on query.petapico.org and 3 on query.nanodash.net. Every other repo has exactly one.

Cause

• TripleStore.get() created its instance lazily without synchronization. Port 9393 starts accepting requests (MainVerticle.java:615) before the loader thread starts (line 628), so several threads make the first call at once, and each could construct its own TripleStore.
• The constructor creates the empty repo, which first creates admin.
• RDF4J's create request (PUT /repositories/<id>) checks whether config.ttl exists and writes it under separate locks. Concurrent create requests for a new repo are therefore all answered with 204. Tested against eclipse/rdf4j-workbench:6.1.0-tomcat, with five rounds of 5 concurrent PUTs, the number of 204s was 5, 5, 3, 4 and 5.
• Each 204 makes that instance run initNewRepo(admin), which writes another init ID.

On an existing store, admin already exists and gets a 409, so this only happens when a store is first built. Consistent with that, the counts didn't change when all three instances restarted on 2026-09-24.

Impact

• The duplicate init IDs: harmless; nothing reads hasRepoInitId.
• The same race on a counted repo would duplicate its npa:hasNanopubCount and npa:hasNanopubChecksum, breaking the full-vs-meta checksum comparison. It hasn't happened on the current stores: all other repos have one init ID, and the checksums match fleet-wide.
• On every start, even on an existing store, each extra instance leaked its HTTP connection pool and idle-connection thread.

Fix

• TripleStore.get(): a volatile field with double-checked locking on TripleStore.class. Later calls still read the field without locking. Construction goes through a private instanceFactory field, so a test can substitute a slow factory.
• TrustStateRegistry.get(): had the same pattern (the worst outcome is a lost cached hash, costing one extra trust-state update). It is now synchronized; it is called rarely.
• Existing duplicate init IDs: left in place, since nothing reads them.

Testing

• New test: TripleStoreTest.concurrentFirstGetConstructsSingleInstance. 16 threads make the first get() call at once against a factory that takes 50 ms; the test asserts that exactly one instance is constructed and returned to all of them.
  • It fails on the old code (checked by applying only the factory change to the old get(): the threads received different instances).
  • It passed 5 of 5 repeated runs with the fix.
• Full suite: 518 tests, 0 failures, 0 errors.

🤖 Generated with Claude Code