Write locks in Acedb [Long and boresome, for code nerds only]

Henry J. Cobb hcobb at fly2.berkeley.edu
Thu Sep 23 16:06:12 EST 1993


	I did not ask the question clearly enough, so let me take another
stab at it.

	My understanding of this program is somewhat incomplete (i.e.: I
haven't managed to read through the TAGS file...), but my presumption is
that the user grabs "write access" to the database and is then allowed an
extended browsing period where they build up a "delta" to be applied to the
database, which is then committed in a single call to sessionClose(true).

	The effect being that other readers of the database will see a
sudden, consistent change to the database, but that only one session will
be allowed into the "gather and modify" mode at a time.

	My suggestion was along the lines of only locking the database at
the "moment" of committing a change, with the option of alerting other
sessions (that were contemplating changes) that a change had been made to
the database, and giving them the option to abandon their (uncommitted)
changes or run a check for overlaps, or whatever.

	I would also like to hack the session ID "numbers" to include the
machine, user and (Unixy) process ID number.  This would be a step along
the way to providing a "virtual server" implemented in the file system
itself.

	The end result of my little plot would have "minor version numbers"
attached to the database where at certain points readers of the database
would notice that the version number had changed beneath them and flush
their little caches, while browsers would be left alone to complete their
"delta" and then when they choose to commit it be informed that a change
had taken place in the database and be allowed to step through the records
involved and combine the original, their changes and the other changes.

	This would, of course, update their "snapshot" of the database and
if further changes occurred while they were back into this browsing mode
they would face the same process over (from the new snapshot) when they
again try to commit.  (This also might prove helpful in merging together
versions of the database from different user sites).

	Now (fortunately) I wasn't born a biologist.  So it really isn't my
place to decide upon the policy of how the multiple writers, multiple
machine case should be handled.  But as a "Bjarne again" hacker I'd like to
implement the mechanism in the cleanest, simplest, most general manner,
exactly once.  I realize that the only program "guaranteed to work on all
machines" is Microsoft Word for Windows, but I do not want to pile up a
bunch of redundant backup systems.  Given the choice, I'd put my locking
code into a few functions and let the end-users replace those as needed.
--
	Henry J. Cobb	hcobb at fly2.berkeley.edu	SFB Tyrant




More information about the Acedb mailing list