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
- Replies:
- Re: ca_put_callback once again Ralph Lange
- RE: ca_put_callback once again Jeff Hill
- References:
- Re: ca_put_callback once again Tim Mooney
- Re: ca_put_callback once again Benjamin Franksen
- RE: ca_put_callback once again Jeff Hill
- Navigate by Date:
- Prev:
RE: subrecord INPx Hinko Kocevar
- Next:
Re: subrecord INPx Eric Norum
- 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
- Navigate by Thread:
- Prev:
RE: ca_put_callback once again Jeff Hill
- Next:
Re: ca_put_callback once again Ralph Lange
- 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
|