Article View: bionet.software.acedb
Article #2837Re: Write locks in Acedb [Long and boresome, for code nerds only]
From: Henry J. Cobb
Date: Thu, 23 Sep 1993 14:06
Date: Thu, 23 Sep 1993 14:06
49 lines
3466 bytes
3466 bytes
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@fly2.berkeley.edu SFB Tyrant
Technical Details
Message-ID:
<HCOBB.93Sep23140612@fly2.berkeley.edu>Path:
arc1-ca.pugleaf.net!gmd.de!Germany.EU.net!mcsun!uunet!spool.mu.edu!agate!fly2.berkeley.edu!hcobbReferences:
<1993Sep23.182732.1681@gserv1.dl.ac.uk>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f6d40,d5cf6c0f3faa5ab0 X-Google-Attributes: gidf6d40,public X-Google-ArrivalTime: 1993-09-23 15:55:19 PST Path: arc1-ca.pugleaf.net!gmd.de!Germany.EU.net!mcsun!uunet!spool.mu.edu!agate!fly2.berkeley.edu!hcobb From: hcobb@fly2.berkeley.edu (Henry J. Cobb) Newsgroups: bionet.software.acedb Subject: Re: Write locks in Acedb [Long and boresome, for code nerds only] Date: 23 Sep 93 14:06:12 Organization: University of California, Berkeley Lines: 49 Distribution: bionet Message-ID: <HCOBB.93Sep23140612@fly2.berkeley.edu> References: <1993Sep23.182732.1681@gserv1.dl.ac.uk> NNTP-Posting-Host: fly2.berkeley.edu In-reply-to: rd@uk.ac.cam.mrc-lmb's message of Thu, 23 Sep 1993 18:20:03 GMT