David asks:
> Hello all.  I've a quick question. If I perform an
> item level lock on a detail dataset using a search
> item that has multiple entries, will Image lock all
> chained entries associated with the key ? Or is it
> necessary to follow the chain and lock each entry
> individually ?

You only need to apply one lock, for the KEYITEMNAME=KEYVALUE that covers
the path you're interested in.

> This is probably obvious, yet I'd like to know for
> certain.

It's obvious when you realize that locking has no connection to the physical
database records at all, i.e. you never physically "lock" a record in any
way.  In fact locking is generally implemented independently of the thing
being locked (at least in Image and other non-relational database and file
systems).

All placing a lock does is put an entry in a table saying "I hereby lock
such-and-such".  The reason it works is that there is an agreement among all
users that they will not update data without having put an appropriate entry
in this table, and they will make sure that there is no conflicting entry in
the table before adding theirs.

If locking actually affected physical records, then you wouldn't be able to
say "Lock all records where KEYITEM=KEYVALUE" before any such records exist.
But of course you *can* do this and then PUT such a record.

This also explains why, when using item locking, if you place a lock of the
form "Lock all records where KEY1=VALUE", then someone else comes along and
tries to say "Lock all records where KEY2=VALUE" where KEY1 <> KEY2 then
Image has no idea whether there is an intersection between the set of
KEY1=VALUE1 entries and KEY2=VALUE2 entries, and thus has to insert a whole
dataset (or database) lock between the two so that the new lock won't be
applied until all other (potentially conflicting) locks are gone.

This is why you want to have all programs agree on which KEY will be used in
each dataset for doing item level locking.  It will avoid the transient
whole dataset or whole database locks that Image applies every time you
switch the key you're locking on.  It's almost impossible to prevent
database deadlocks when doing complex locking and using more than one KEY
per dataset in your lock predicates.

G.