Re: Dead locking Information

Discussion created by ca.portal.admin on Oct 17, 2005

What follows is only intended to satisfy the morbid curiosity of those
who can't sleep well until they know why something works the way it
works. There is little useful information in what follows. (OK; here's
the useful part: Margaret is absolutely right.... you want to minimize
the cases where an ADSO dialog is keeping retrieval locks. You can do
this by selectively identifying which dialogs require retrieval

Retrieval locking in ADSO came about as the result of a ""hole"" in the
original implementation of the currency passing that ADS uses when it
terminates one run unit and fires up another (e.g. when the map is

At the point the passing run-unit is shut down, it's currencies are
saved in a currency block in storage, and notify locks are established
for those currencies which will be passed to the recieving run-unit.

When the new run-unit is established, the notify locks tell the system
whether or not any of the currencies have been invalidated, as would be
the case if records had been ERASEd, new one's STOREd, etc. Various and
sundry things happen during the establishment of the currencies and
locks for the new RU to ensure that it does not make incorrect
assumptions arout currency.

The hole which existed in this scheme centered around retrieval-only ADS
run-units passing currencies to update ADS run-units. Unless you have
requested system-wide retrieval locking (rarely if ever used), there are
no locks of any kind kept for retrieval run units. That meant that
WHILE a retrieval run-unit held a currency (e.g. next in set), it was
possible for a update to invalidate that currency unbeknownst to the
retrieval RU. Changes that happen DURING the run-unit happen BEFORE the
notify locks are set, therefore you end up setting a notify lock on an
incorrect currency. If that currency gets passed to an update run-unit,
and is used by some update verb (e.g. STORE), chains can (and did) get

It's a very small hole; it only exists during the life of a run-unit.
The original ""fix"" was to detect the passing of currencies from a
retrieval RU to an update RU and abort the thread (which I believe will
still happen). I dimly recall that people were also told they could
ready in UPDATE mode to get around the abort.

The ADS retrieval locking solution closes the hole, by establishing
currency locks on records as they are touched. The downside, as
Margaret points out, is that this creates the possibility for lock
contention. You certainly don't want to be holding locks you don't need
to be holding.

Way back when there was some agitation from certain quarters that ADS
should be doing notify locking (rather than currency locking) during the
life of a retrieval RU.... but for various (probably good) reasons this
isn't the way it was implemented.

* DQC *

P.S. Thanks for the kind comments about ""Understanding..."". Most of the
concepts are likely still valid; the mechanics of detection have changed
as noted, as has the degree of control in victim selection and (of
course) the control blocks.