monotone - Bugs: bug #15079, Saner handling of database...
You are not allowed to post comments on this tracker with your current authentication level.
bug #15079: Saner handling of database read/write transactions
Submitter: | Nathaniel Smith <njs> | ||
Submitted: | Sun 27 Nov 2005 11:41:02 AM UTC | ||
Category: | storage system | Severity: | 1 - Wish |
Item Group: | code cleanup | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | ||
mtn version --full: |
|
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
CC list is empty
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Powered by Savane 3.13-f8d8.
Corresponding source code
Ideal behavior:
-- all commands acquire either a read lock or a write lock
-- they either succeed entirely (wrt locking, anyway), or fail immediately at the beginning of their run
To do this right, we should have a static difference between "readable db" and "readwriteable db", I think. (This makes certain kinds of caching harder, of course, logically non-writing operations might in fact want to update caches or something... fortunately we have no such on-disk caches ATM.)
Then each command could receive one sort of db or the other, and pass it on to each function it calls. Then all the above properties could be achieved statically.
This full solution is a bit intrusive, though IMO fully worth it. In the mean time, it would be good to, e.g., have read and write transactions, and ensure at run time that write operations only occurred inside write transactions. This solution is bad in the long run, though, because with it we will have another class of bugs that always come back sooner or later.