avoid using a second db connection for writes
authorJoey Hess <joeyh@joeyh.name>
Wed, 20 Oct 2021 16:32:46 +0000 (12:32 -0400)
committerJoey Hess <joeyh@joeyh.name>
Wed, 20 Oct 2021 16:32:46 +0000 (12:32 -0400)
commitd0ef8303cf8c4f40a1d17bd134af961fd9917ca4
tree08de99bc9569a4e163c5a3940d858328d558661f
parentf5b642318dc33f9cee41cac08a276cae37878633
avoid using a second db connection for writes

This is a potentially breaking change in a very delicate area. However,
examining the code path for writes, I don't see any benefit to opening a
second db connection for them. If the write throws an exception,
commitDb will retry it with a new db connection.

A potential benefit to not opening a second db connection, beyond using
less resources, is it just might avoid problems in WSL with sqlite that
I have hypothesized are caused by multiple db connections.

Commit 5f9eff3f32e0101ee673c3dde221f0f27f32e3c8 explains why it needs to
shut down the db connection to force the database to be updated on disk:
When closeDb does not get called, garbage collection of DbHandle may not
give the workterThread time to cleanly shut down before git-annex exits,
resulting in a recently written change not reaching disk.
Database/Handle.hs