Re:

> > Item # 1:  Ranked # 6:
> >
> > Provide concurrent TurboIMAGE read-only DBLOCK mode
> > (guaranteed repeatable read): Allow multiple readers, but force
> > all DBLOCKs for WRITE access to be treated serially while
> > READ lock is in effect.

...

I think Steve did a great job describing the enhancement request.

I wish I'd described it even half this well when I suggested it years ago
(was it at SIGIMAGE in Reno or the one after that?).  My motivation was
two-fold: a proper locking system always provides both exclusive read/write
locks and sharable read-only locks (with both kinds of lock requests having an
optional "block until lock granted" capability).  I noticed that IMAGE lacked
sharable read-only locks.  I also noticed that we could do better on the
TPC-A (or was it TPC-C?) benchmarks if we had such a lock ... hence the
enhancement suggestion!  (I made several other enhancement suggestions
to benefit the TPC benchmarks :)

> The suggested enhancement is to create a new type of database lock, a "read"
> lock with the following properties:
>   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.

...

>   3) As long as any "1-6" lock is held on an item, any attempt to obtain a
> "read" lock on that item (or higher/lower level...) will be
> denied/suspended. Whether the "read" lock should have both conditional and
> unconditional mode options is a topic for further discussion.

Should have both modes, just like other locks.

>   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.
>   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.

I think I'd not focus a lot on 4 & 5, but put them as a performance footnote
(e.g.:  If you have a DBLOCK mode 7, and you call DBLOCK mode 1, then if
no one else has a read lock, you'll get the read/write lock immediately.  If
one or more other people are sharing the read lock, and you specified "wait",
then your read lock is released, and you'll be put in the queue of processes
waiting for a read/write lock)

thanks,

Stan

Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler