ca.portal.admin

Re:Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?

Discussion created by ca.portal.admin on Mar 9, 2010
then perhaps the real question becomes:=3D20 =3D20 does Ms Kline need this =
information real time as it happens, or can=3D20 daily reports suffice=3D20=
=3D20 if the latter, then certainly the log can be interrogated and all=3D=
20 necessary information can be retrieved=3D20 if the former - good luck - =
even if you sat all day executing lockmon=3D20 you MIGHT see stalls buildin=
g, but many deadlocks could come and go=3D20 between two hits of the ENTER =
key=3D20 =3D20 chris=3D20



The information transmitted is intended only for the person or entity to wh=
ich it is addressed and may contain CONFIDENTIAL material. If you receive =
this material/information in error, please contact the sender and delete or=
destroy the material/information.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
" Don - question, accepting completely the NOTIFY locks used by ADS across pseudo-converse. Here's a scenario.

1) The dialog does OBTAIN on record types A, B and C, and a MODIFY of C in the premap. At the pseudo-converse the update of C must be COMMITTED when the FINISH of the run unit occurs - but ADS maintains NOTIFY locks on the 3 record types.

2) Now - in the response process the dialog does an OBTAIN and MODIFY of record type D - when ADS BINDs the Run Unit would it not re-acquire the NOTIFY locks as database run unit locks PRIOR to doing the OBTAIN and MODIFY of record type D?

3) So it would be possible for the A, B or C record types to interact with other active tasks - thus causing confusion for the developer who only sees record type D referenced in the response process code?

Just curious - as this is the sort of scenario that I believe the CAS user is seeing.

Cheers - Gary

Outcomes