I’m rewriting the locking logic in Sonic to leverage lifetimes instead of opening read/write locks manually. It’s so error prone that some issues (if true) have been lying around for a long time.
For example, in multiple places this pattern is used, where a lock is used to prevent concurrent actions like backup_item:
// in impl StoreKVPool
// Acquire access lock (in blocking write mode), and reference it in context
// Notice: this prevents store to be acquired from any context
let _access = self.store_access_lock.write().unwrap();
However, the pool looks like pool: Arc<RwLock<HashMap<StoreKVKey, Arc<StoreKV>>>>, which means StoreKVs (which contain database connections) are cloned in multiple places and can be used at any time. Because of this, one can write data in the middle of a backup (which shouldn’t be possible).
I’ll try fixing this at some point, or proving this cannot happen (because of another mechanism downstream).
This issue might be related to #274 (I can’t confirm).
I’m rewriting the locking logic in Sonic to leverage lifetimes instead of opening read/write locks manually. It’s so error prone that some issues (if true) have been lying around for a long time.
For example, in multiple places this pattern is used, where a lock is used to prevent concurrent actions like
backup_item:However, the pool looks like
pool: Arc<RwLock<HashMap<StoreKVKey, Arc<StoreKV>>>>, which meansStoreKVs (which contain database connections) are cloned in multiple places and can be used at any time. Because of this, one can write data in the middle of a backup (which shouldn’t be possible).I’ll try fixing this at some point, or proving this cannot happen (because of another mechanism downstream).
This issue might be related to #274 (I can’t confirm).