Hmmm. It depends of course on how much is deemed "significant runtime
overhead". I imagine a solution along the following lines: All puts that
occur during asynch processing (i.e. target record's PACT==TRUE) are
redirected (by dbPut) into a queue (linked list or cicular buffer or
some such thing), where pairs consisting of {field address, new value}
are stored. Only when the record completes processing, the puts stored
in this list actally happen. After that eventual re-processing is done.
The advantage is that for the 'normal' situation (either PACT==FALSE or
dbScanLock is active) the only additional overhead is the check for PACT
and the check for an empty queue after processing. These are effectively
two machine instructions. Only if no scan lock is active and PACT==TRUE,
real overhead will occur. Even this overhead is not too great a cost,
IMHO, if it solves the problem.
I haven't spent any time thinking about the most clever representation
of the 'deferred puts' in the queue but certainly this can be worked
out.
What do you think?
