Re: Assuring consistent databases....

[mrk@aps.anl.gov (Marty Kraimer)]

Nick Rees,

Currently the following is true.

1) What is locked for record processing is a lock set.
2) CA (actually dbPutField) locks before puting and unlocks after.
3) There is no way to ensure that nothing else cause record processing
   between ca puts.


One thing you could do immediately to solve your problem is to let the
related values be sent in an array (the entire array is sent between
lock and unlock). If the put also cause the record to process you have what
you want.

The above probably can not be done with standard record types but you could
easily write a special record type.

Marty Kraimer



> From npr@jach.hawaii.edu Mon Sep 12 13:33 CDT 1994
> Date: Mon, 12 Sep 94 08:34:54 HST
> From: npr@jach.hawaii.edu (Nick Rees)
> To: epics_applications@aps.anl.gov
> Subject: Assuring consistent databases....
> Content-Type> : > text> 
> Content-Length: 1506
> 
> Hi,
> 
> How do you insure that if database values are related, they are always
> updated consistently? If I do a number of consecutive channel access
> puts (or gets) - potentially from the network - I want to ensure that
> these operations:
> 
> 1. Don't interrupt processing in a lock set that uses, or changes,
>    these two values.
> 
> 2. Don't get interupted by record processing during the database update.
> 
> I am prepared to guarantee that the CA gets and puts were done
> consecutively, with no ca_pend_io separating them, but I am not sure
> what else is needed.
> 
> I feel that this must be a common problem, but it has bugged me for a
> while, and I haven't got a satisfactory answer yet. (Epics is so
> atomic, and this is a structured data problem.) If there is no
> satisfactory answer, how difficult would it be to provide the feature?
> Without it, I am afraid my servo application will glitch every few
> seconds, which is not a terribly nice feature (it is the classic
> telescope servo - the telescope servo needs UTC, position, velocity
> tuples which are consistent).
> 
> The problem is really the same as the classic `update anomolies' which
> my university days told me were the reason for the `nth normal forms'
> in relational databases. It is also the reason for the existance of the
> mutex semaphore.
> 
> 
> Nick Rees
> 
> Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
> 660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
> Hilo, HI.  96720                          Internet: npr@jach.hawaii.edu
>