The Client Data Store implementation is based upon Sqlite3, and per the faq we should be using file locking to ensure that multiple processes attempting to update the data store concurrently don't corrupt the data base.
Short lived operations that are just querying the data store content should be read locking the backing DB file for the duration of their run.
Longer lived operations that may be updating the data store content after querying it should be write locking the backing DB file for just the duration of those operations, but shouldn't rely on previously fetched data for follow on actions.
Potentially use something like the gofrs/flock or roll our own based upon the Linux syscall.flock()
The Client Data Store implementation is based upon Sqlite3, and per the faq we should be using file locking to ensure that multiple processes attempting to update the data store concurrently don't corrupt the data base.
Short lived operations that are just querying the data store content should be read locking the backing DB file for the duration of their run.
Longer lived operations that may be updating the data store content after querying it should be write locking the backing DB file for just the duration of those operations, but shouldn't rely on previously fetched data for follow on actions.
Potentially use something like the gofrs/flock or roll our own based upon the Linux syscall.flock()