Steve Dirickson eloquently writes (>):

>   2) In fact, an expected record might not even exist. One variant
> results when the displayed record is deleted "behind the back" of the
> viewing user. Another involves deletion of adjacent records....

Another, more important issue I believe, is traversal of complex data
structures comprised of entries in multiple datasets.  The possibility of
data entries changing, disappearing and being added during the traversal
of such structures requires, in my opinion, strong locking.  I can't
imagine how to explain to a user that their job "blew off" and should be
re-run (and how to tell this issue from a real structure issue) - the
infamous Microsoft "just reboot and try it again" approach.  Perhaps it
is because I develop systems for banks, where this is NOT an option.
It isn't desirable anywhere, but intolerable in a banking system.

>   1) Any number of accessors can obtain a "read" lock on the same item
> simultaneously (realizing that "item" may actually be at the dataset or
> database level). The usual cautions about mixing locks at different
> levels, and about MR-ing yourself into a deadlock, would apply.

Exactly why I proposed this enhancement six or seven years ago.  I've
wanted it since 1983 or so.

>   4) Provided that only a single accessor currently holds a "read" lock
> on an item, that accessor is allowed to "upgrade" the lock to a "1-6"
> lock.  This "lock upgrade" operation must be atomic when viewed from the
> "outside"; i.e. such that no other accessor can "jump in" between the
> release of the "read" lock and the establishment of the "1-6" lock and
> lock the item.

I think this is somewhat dangerous and unpredictable behavior and may not
be worth the trouble to implement.  I would never use it, as I only use
features which I can fully count on.  Perhaps this is necessary for
reasonable SQL compatability, in which case, it might be useful, but I
wouldn't want them to delay releasing this feature while working on this.

If it were to queue (like any other writer), and thus, be predictable
(in that it would not fail, unless a conditional lock was requested), it
might be worthwhile.  Perhaps I misunderstood the implication of "provided
that...".

>   5) Likewise, an accessor holding a "1-6" lock on an item (which is, by
> definition, the only accessor holding any kind of lock on that item) may
> "downgrade" the "1-6" lock to a "read" lock atomically.

Again, I am not sure it is worth the effort, but I suppose I could be
swayed by a good example (actually, one thing I like about 3000-L is that
nearly all of us can be swayed by a good example or argument).

>   6) Attempting a DBPUT/DBDELETE/DBUPDATE while holding only a "read"
> lock under DBOPEN modes (well, "mode" at the moment) requiring locks for
> modifications will produce the same "no covering lock" (-12) error as if
> no lock of any kind were held.

> The "obvious" implementation would simply create new DBLOCK 'mode'
> values 7 through 12. As is typically the case with "obvious" solutions
> to difficult problems, this one should be viewed with suspicion. Item 1)
> in particular can get tricky when working with multiple lock sets on
> different levels that overlap/are proper subsets of/encompass/etc. other
> lock sets on the same or different levels.

I am of the opinion that only the equivalent of mode 5 and 6 (using lock
descriptors) is needed.  I imagine systems using database and single
dataset locks to be too simple to matter.  Perhaps the equivalent of modes
1 through 4 is trivial to implement with the others.

I would like us to make a simple enough request that HP (with our guidance
as to what we would really use and what we wouldn't) might actually find
the resources to implement and deliver this in a reasonable timeframe.

> For those at the intersection of "don't already know" and "care", this
> type of lock is called the "Repeatable Read" level of "Isolation"; that
> "I" being the one in "ACID", the
> "Atomicity/Consistency/Isolation/Durability"
> properties of database transactions. We hear a lot less about ACID in
> the TurboIMAGE world than do the people in RDBMS/SQL-land <insert
> appropriate wisecrack here>, but the properties are just as
> relevant--and just as important--here on the network side of the line.

Very good summary.

Thanks for the details.  I have a folder full of similar notes made in
1983 when I discovered this issue.  Larger systems with more online and
web queries have only made the issue worse, as have multiprocessor
systems (process holding lock generally executing at the speed of a
single processor).

Rick