Re: Does DISP work for DB OUT links? Related question

[Marty Kraimer <mrk@aps.anl.gov>]

Benjamin Franksen wrote:
> 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?


You are correct. This is a really nasty side effect of asynchronous processing.

The following assumes a passive record.

If a value is written to a record between the two phases of record processing 
the following is done.

The value is written to the record. If the field has pp(TRUE), i.e. process 
passive, the record will be processed again when the record completes 
asynchronous processing.

Thus can lead to strange side effects.

Kay Kasemir and Jeff Hill just told me of one.

Assume a bo record has the value 0.

Two puts are sent to the record. The first is 1 and the second is 0.

If the first asynchronous completion occurs before the second put everything 
works just like for synchronous records. Two channel access monitors will be 
issued. The first returns 1. The second returns 0.

If the second put occurs before the asynchronous completion from the first, NO 
ca monitors are issued. The explaination is as follows:

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.

Thus asynchronous records can lead to strange behavior.

See the 3.14 Application Developer's Guide
    Chaper: Database Locking, Scanning, and Processing
    Section Guidelines for Asynchronous Records
    Section: Cached Puts
    Section putNotify

I see no easy solution and perhaps no solution without significent runtime overhead.


Marty Kraimer