I would think that it's because the program is doing too much with the
lock in place.  If you lock, then have the program do some other things,
your system performance will degrade.

If you lock and only do what must be done to the locked record, you only
tie up resources for the time that you absolutely need them.

Not to mention many users running the same online program.  The users,
and your system, would not be happy excessively waiting for the unlock
to take place.

        -----Original Message-----
        From:   Bruce Toback [SMTP:[log in to unmask]]
        Sent:   Thursday, November 19, 1998 9:04 AM
        To:     [log in to unmask]
        Subject:        Re: TurboImage Locking

        Roy Brown writes:

        >In practice, you might see more conditional lock failures, due
to longer
        >lock periods from the queued unconditionals. But this would
only occur
        >if you had defects in your locking strategy to begin with.

        Why would queued locks be a sign of a defective locking
strategy?

        -- Bruce



------------------------------------------------------------------------
--
        Bruce Toback    Tel: (602) 996-8601| My candle burns at both
ends;
        OPT, Inc.            (800) 858-4507| It will not last the night;
        11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my
friends -
        Phoenix AZ 85028                   | It gives a lovely light.
        btoback AT optc.com                |     -- Edna St. Vincent
Millay
        Mail sent to [log in to unmask] will be inspected for a
        fee of US$250. Mailing to said address constitutes agreement to
        pay, including collection costs.