ca.portal.admin

Re: Dead locking Information

Discussion created by ca.portal.admin on Oct 17, 2005
Bill,
Most deadlocks these days are caused by ADSO retrieval locking which
came into existence with release 12.0, around 1993 and has been causing
grief ever since. Because CA thought they were fixing a bug and not
adding a new feature, they did not publish the change, at first. I've
attached some information from the current ADS manual about it and also
a program I wrote to extract all dialogs from the dictionaary with the
retrieval locking indicator and whether the dialog is update or
retrieval only. It's very crude and puts the records into a file so they
can be sorted or downloaded to a spreadsheet. The list will also
indicate whether the dialog links or invokes another dialog. The first
thing you can do, is turn retrieval locks off for all dialogs which are
retrieval only and don't link to other dialogs. Also, monitor the log
for deadlocks because often it is only a few dialogs causing the
problem. Look for errors of ""0361"" or ""0306"". Another thing that happens
with retrieval locking deadlocks is that the dialog run unit terminates
and then starts up again at the next DML command. This is what causes
the ""0306""s because currency has been lost. If the problem dialogs are
update dialogs, that are linked to from another dialog, you will want to
try and isolate the update functions as much as possible, by putting
them in mapless dialogs, passing DBKEYS for them to re-establish
currency and using the LINK NOSAVE option to execute them. If you can
give me a scenario you're dealing with, I can give you more specifics on
how to handle it. Let me know if you have any questions on this and good
luck!
Margaret


-----Original Message-----
From: Bill Allen [mailTo:ARCHCONB@AOL.COM]
Sent: Friday, October 14, 2005 10:32 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Dead locking Information

Hello All:

Anyone have any tips, tricks, techniques, documentation, white papers
or CA World Presentations on Dead Locking?

I would be grateful if you would share them with me. I already have the
CA World 2004 Presentations.

Bill Allen
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dead locking Information
"Warning!!

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

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

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

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.

* DQC

Outcomes