GavinHuttley / scinexus / 35062048326

100%

push

github

API: a writable sqlite store claims its lock as it opens

The db property claimed the lock on first access, and a read is an access,
so the first worker thread to read a writable store became its owner.
Ownership is thread scoped, as a000bd41154f records: it changes who may
release a lock, not who may take one. The master could then neither write
nor release it, close() left it on disk, and the next session was refused by
a thread id that no longer exists -- with nothing said at the moment it
happened.

A writable store now opens its connection and claims its lock while it is
being constructed, on the constructing thread, which by the model is the
master. By the time a worker reads, the lock is already held and nothing in
the read path reaches for it. That alone would still leave a store whose
lock had been released by hand open to the next worker that read it, so the
implicit claim in db is also confined to the session that opened the store,
and the calls that change what the store holds are refused from any other.
Reads are not: that is what the worker threads are for. close() now warns
when the lock it holds is not this session's to release, so the one path
that still strands one -- a store constructed inside a worker thread, where
is_master_process() is false -- says so rather than going quietly.

A lock the constructor cannot take is passed over in silence, because
opening a store for writing is not writing to it: the same call serves a
caller who means to read, and one who means to clear a lock left behind.
The write that meets the lock raises, as it did before. Claiming is gated on
is_master_process(), as DataStoreDirectory gates creating its directories,
so a store rebuilt in a worker process is unchanged. Two things now happen
earlier: the file and schema exist as soon as a writable store is
constructed, and a store built and abandoned without close() warns, because
it holds a lock from the moment it exists.

24 of 24 new or added lines in 1 file covered. (100.0%)

2880 of 2886 relevant lines covered (99.79%)

8.85 hits per line