git-annex/Database
Joey Hess d0ef8303cf
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 5f9eff3f32 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.
2021-10-20 12:32:46 -04:00
..
Keys remove unused code 2021-07-30 18:01:36 -04:00
Benchmark.hs eliminate single/multi writer distinction 2021-10-20 12:26:30 -04:00
ContentIdentifier.hs eliminate single/multi writer distinction 2021-10-20 12:26:30 -04:00
Export.hs eliminate single/multi writer distinction 2021-10-20 12:26:30 -04:00
Fsck.hs eliminate single/multi writer distinction 2021-10-20 12:26:30 -04:00
Handle.hs avoid using a second db connection for writes 2021-10-20 12:32:46 -04:00
Init.hs more RawFilePath conversion 2020-11-05 18:45:37 -04:00
Keys.hs eliminate single/multi writer distinction 2021-10-20 12:26:30 -04:00
Queue.hs eliminate single/multi writer distinction 2021-10-20 12:26:30 -04:00
Types.hs simplify and speed up Utility.FileSystemEncoding 2021-08-11 12:13:31 -04:00