[locking] Get a revision while a batch is active #17
Conversation
| ); | ||
|
|
||
| // Read the uncommitted value while the batch is still active. | ||
| let val = db.kv_get("k").unwrap(); |
There was a problem hiding this comment.
My expectation here would be that kv_get would return no value as the key has not been committed. db.kv_get() should return against the latest revision. In this case its returning against an uncommitted batch which makes me think a mutation has taken place on disk.
ref.
Lines 710 to 717 in 8d46653
There was a problem hiding this comment.
I see your point, for the current user who open the batch and want to read the uncommitted changes. It is desired the user can read it. But the other concurrent user shouldn't read it.
There was a problem hiding this comment.
i think this will be further complicated by the API changes. I think we should proceed with improving the concurrency of this now though; this seems to be heading the right way for now.
There was a problem hiding this comment.
yeah, talked to @hexfusion offline, with this change, there is still something needs to be improved that DB should not has APIs that would expose the staging changes. And user should directly interact with a DBRev to write/read their uncommitted changes. I will have a follow up PR for it. But agree would want to merge this as incremental changes.
6b437ef to
52d0775
Compare
| let old_value = merkle | ||
| .remove(key, header.kv_root) | ||
| .map_err(DBError::Merkle)?; | ||
| drop(rev); |
There was a problem hiding this comment.
This should not be needed; rev can go out of scope and get cleaned up after the construction of the return value.
There was a problem hiding this comment.
If I remove it, there's error showing borrow of 'self.m' occurs here on L887
There was a problem hiding this comment.
Interesting. I wonder if you instead don't even have rev, something like:
let (header, merkle, _)= self.m.write().latest.borrow_split();
9a1864b to
cf0b3bf
Compare
Closes #37
This PR breaks the mutex lock on DBInner to separate ones on latest batch and revisions. So that users can get a revision while a batch is active. It also allows users to read their writes for a uncommitted batch.
A follow up PR will associate revisions with root hashes to ensure a revision has static meaning.