Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 24 Nov 2010 12:52:16 -0700

> One major problem is that generic code can't know whether it is 
> safe to re-run a put that fails for this reason or not.  If there 
> is significant I/O or other processing in the chain of records 
> that leads up to the record that's busy then it might *not* be 
> safe to repeat the put operation.

Presumably if two put notify requests arrive independently from two clients at almost the same time then we are happy to accept that we can't predict the order in which they will be executed, but also at a functional level we hope that initiation of the subsequent request is postponed until the first one completes in entirety.

Is it possible to know when initiating a put notify if a put notify is already pending in any part of the processing chain that it is being initiated, and if so, chain initiation of a subsequent put notify to completion of the pending put notify? My naive understanding is that all records in the same processing chain share a single lock set lock, and also a single put notify queue?

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Wednesday, November 24, 2010 10:36 AM
> To: Jeff Hill
> Cc: 'Benjamin Franksen'; [email protected]
> Subject: Re: ca_put_callback once again
> 
> On Wednesday 24 November 2010 10:36:24 Jeff Hill wrote:
> >
> > Do I understand correctly, that with this source code change in
> dbPutNotify
> > the system now sends a failure response for the put callback request
> when
> > this situation arises? That result, while it is arguably superior to
> > current behavior, isn't particularly satisfying on a functional level
> > because it is creating duplicated code in the client applications.
> > Presumably, now all clients need code that will keep reissuing the
> put
> > callback request until it is successful.
> 
> One major problem is that generic code can't know whether it is safe to
> re-run
> a put that fails for this reason or not.  If there is significant I/O
> or other
> processing in the chain of records that leads up to the record that's
> busy
> then it might *not* be safe to repeat the put operation.  It doesn't
> matter
> where we propose to put the retry code, the same issue arises; only the
> person
> designing the overall system can work out what the correct response is.
> 
> Ben's proposal at least makes it possible for the issue to be detected
> by a
> client so that an application-specific decision can be made when this
> happens.
> 
> This is definitely a 3.15 (or later) change by the way, and there is
> already a
> major modification to the putNotify code in the queue in front of this
> so I'm
> not going to be able to apply Ben's changes for some time, giving us a
> chance
> to work out the consequences properly.
> 
> - Andrew
> --
> If a man is offered a fact which goes against his instincts, he will
> scrutinize it closely, and unless the evidence is overwhelming, he will
> refuse to believe it.  If, on the other hand, he is offered something
> which affords a reason for acting in accordance to his instincts, he
> will accept it even on the slightest evidence.  -- Bertrand Russell

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System