[Metakit] Using Rollback to implement concurrency

[Jean-Claude Wippler]

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