Stimms wrote:
The basic idea would be to use mutexes to allow
multiple simultaneous readers or a single writer
(locking out simultaneous reading). When the writer
had finished it's task it would commit, signal the
other processes that they should rollback (thus
reloading the newly commited storage) and then release
the write lock.
[...]
The question is if rollback would work in this manner?
Can rollback handle that the datafile has been
modified since last access and will it update all
active views correctly?
Maybe. Yes, multiple readers *and* a single writer can work together
as you describe. The writer has to signal all readers, and they all
have to rollback before a new commit by the writer is started (any
writer, it could become another one). Rollback is a mis-nomer
clearly, what it means in this scenario is: revert to on-file state.
But the problem is that all readers have to re-attach all their views
(well at least all those which are modified). I.e. re-execute the "v
= db.one[2].three" statement that corresponds to the proper view on
file. This is not trivial, if say db.one had a new row inserted at
position 1, then the above will need to be adjusted since the
original view is now one[3] i.s.o. one[2]. So in the case of only
simple top-level views, it ought to be doable, but with subviews this
might not be feasible in general.
There are more avenues to explore, such as using the "commit-extend"
mode. What this does is leave the original readers unaffected. So
one refinement would be:
- readers open and use as needed
- a single writer opens and makes changes
- after a normal writer commit is done
- signal all readers to rollback
- force all further writes to use commit-extend
- once all reader rollbacks have been acknowledged
- allow normal commits again
The above allows even more concurrency (readers never lock, and the
writer need never wait for all readers to complete their rollback),
but it does require that occasionally the datafile gets compressed at
a time of no activity. With care, this cleanup phase can probably
even be made to work while readers are still active.
-jcw
_____________________________________________
Metakit mailing list - Metakit@equi4.com
http://www.equi4.com/mailman/listinfo/metakit
