David Binger writes:
>
> On Apr 11, 2007, at 5:17 PM, Andrew Bettison wrote:
>
> > I just check the file size on every sync and commit.  If it's
> > increased since we last synced or committed, then other processes
> > have committed in the meantime.  We read the new transactions from
> > the last point we reached, up to the new eof.
>
> I think we should implement this now for FileStorage when it is opened
> in read-only mode.  Currently, FileStorage in read-only mode does not
> get any updates.

You could do that.  If you don't want to worry about the race condition
of one process reading while another appends, then it's pretty
straightforward.

However, I can't see the value of an implementation susceptible to that
race, unless you can somehow make all reader processes quiescent while
writing takes place (by which I mean prevent them from doing a
FileStorage.sync() or FileStorage.commit()).  You'd also have to be
prepared to terminate all reader processes before packing, and re-start
them after packing, because the reader processes could not know which
OIDs to invalidate upon reading the packed file.

I guess what I'm getting at is that, like all things concurrent, it
ain't as simple as it first looks.

I'm happy to make SharedFileStorage publicly available.  It still
suffers from the index memory overhead issue, which doesn't stop it from
working, just potentially consumes a lot of memory, in proportion to the
number of processes multiplied by the number of objects.  For small
databases (few objects), it's not such an issue, so SharedFileStorage
may still have some value to Posix-based Durus users.

Legal question: would shared_file_storage.py be considered a "derivative
version" of Durus under para. 2 of its license?  In other words, must it
and its derivatives bear the CNRI copyright message?

--
Andrew Bettison