1994 1995 1996 1997 1998 1999 2000 2001 2002 <2003> 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 <2003> 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Does DISP work for DB OUT links? Related question |
From: | Marty Kraimer <[email protected]> |
To: | Benjamin Franksen <[email protected]> |
Cc: | [email protected] |
Date: | Thu, 28 Aug 2003 07:35:14 -0500 |
Marty Kraimer wrote:
Benjamin Franksen wrote:
Marty Kraimer wrote:
Benjamin Franksen wrote:
I mean, if DISP=TRUE, does this also disable setting fields via db (out) links?
dbPutField and dbPutNotify requests are disabled.
This it only disables Channel Access puts.
Database links are NOT disabled.
Channel Access client puts (this includes CA links) are disabled.
Is there any way to disable *all* puts to a record?
No.
Marty,
thanx for your answers. I just asked myself what happens when the record is being processed (scan lock active). Then remembered that records with out links are *always* in the same lockset with the target record (even if NPP NMS), so this will prevent the record that is being processed from outside field changes.
Next question: If the record is being processed asynchronously, i.e. PACT=TRUE but scan lock is not active (record is waiting for the prcosess callback). Then the fields are not protected from changes via other records' output links, correct? I.e. one cannot rely on such a record's fields having the same values as when the callback was set up during the first call to process?
The put of 1 occurs: 1 is written to the VAL field The record starts synchronous processsing The put of 0 occurs 0 is written to the record A flag is set requesting that the record be reprocessed The asynchronous completion because of the first put occurs. Record support compares MLST and VAL. Since they are the same because of the second put, no monitor occurs. The record is processed again The record starts asynchronous processing The asynchrononous completion occurs. MLST and VAL are both still 0. Thus no monitors.
See the 3.14 Application Developer's Guide Chaper: Database Locking, Scanning, and Processing Section Guidelines for Asynchronous Records Section: Cached Puts Section putNotify