In article <[log in to unmask]>,
Greg McDaniel <[log in to unmask]> writes
>Could someone tell me if there are any problems with some programs doing
>conditional item level locks while other programs are doing
>unconditional item level locks.  The programs are all locking the same
>item.  All of our code currently use conditional item locks but we would
>like to move to unconditional locks for some applications.  Hence we
>would end up with a mixture of conditional/unconditional item locks.
>
'A lock is a lock' once you have got it.

In principle, a conditional lock is as likely to fail because another
conditional lock has succeeded as because an unconditional lock has
succeeded.

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.

The trouble with an unconditional lock is that you 'launch it and lose
it' - your app goes away until it succeeds, no matter what. Not always
desirable. Although you do have to decide what to do when a conditional
lock fails, at least are aware, and *can* decide.

We go back to the user with 'Conflicting Activity -try again' in online
mode, when nothing has been updated, and we do up to 1000 retries at
1-second intervals in batch or quasi-batch mode.

We had a few uses for unconditionals in the middle of long sequences of
updates, where we can't recover from a lock failure in any easy way, but
if we were rewriting the app, or writing a new one, we'd use the DBXxxx
calls now.

Other uses are then just for 'must have' single hits. In these cases, a
conditional lock in a Pause/Retry loop may still be better; as above,
you keep control.


I said that most of our batch job locks are Conditionals in Pause/Retry
loops. Another good reason for this is that we have multiple databases,
and so need to use MR.

Do you use MR capability? You have to be especially careful with
unconditional locking if you use MR. If process 1 holds A locked, and
asks for B unconditionally, while process 2 holds B locked and asks for
A unconditionally, your HP3000 goes away, in whole or part...

The ideal rule is 'never ask for an unconditional while already holding
a lock of any sort'.

Failing that, as you sometimes must, you need a global lock precedence
scheme, adhered to by all your developers, which says 'never ask for an
unconditional on a dataset which is higher in the list than any dataset
you currently have locked'. This is open to human fallibility, and the
price of getting it wrong is high...

--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'