Feature #2611: mon: Single-Paxos
Subtask #2621: mon: Single-Paxos: synchronize the MonitorDBStore of oblivious monitor
Subtask #2739: mon: Single-Paxos: Sync: Synchronize the store of a drifted monitor
mon: Single-Paxos: LevelDBStore: Make iterator thread-safe
The current iterator implementation iterates directly over the database state, even if there are concurrent updates.
Since leveldb offers snapshot support, giving a consistent read-only view of the state of the database at the point in time at which the snapshot was taken, we should make the iterator use a snapshot instead of using directly the current database state.
This is specially useful for synchronizing the monitor stores, while allowing transactions to be applied onto the database (i.e., allowing Paxos proposals to be committed) while still keeping a consistent view of the store state at the moment the synchronization started.
#1 Updated by Joao Eduardo Luis almost 11 years ago
- Status changed from In Progress to 4
#2 Updated by Joao Eduardo Luis almost 11 years ago
- Parent task changed from #2621 to #2739
#3 Updated by Joao Eduardo Luis almost 11 years ago
Just a couple of notes on this regard:
- We changed KeyValueDB:
- Added a Whole-space iterator interface
- Implemented the prefix-based iterator in terms of the Whole-space iterator interface
- Added a virtual abstract get_iterator() function
- Added a virtual abstract get_readonly_iterator() function
- Implemented the prefix-based get functions for both the iterator and the read-only iterator in terms of the new functions
- We changed LevelDBStore:
- Implemented KeyValueDB's Whole-space iterator interface
- Implemented a read-only iterator based on the Whole-space iterator interface
- Added the getters for both the whole-space iterator and the whole-space read-only iterator
- LevelDBStore's read-only iterator:
- Relies on leveldb's snapshots
- Currently there is no apparent difference between this implementation or the whole-space iterator itself (this was concluded through testing). However, I feel way more comfortable relying on an iterator that explicitly uses an iterator, instead of hoping that leveldb's inner workings get to do that for us -- although it currently does, I can't but wonder if it will always like that.
#4 Updated by Joao Eduardo Luis almost 11 years ago
- Status changed from 4 to Fix Under Review
- % Done changed from 90 to 100
#5 Updated by Joao Eduardo Luis almost 11 years ago
- Status changed from Fix Under Review to Resolved