chuqui@nsc.UUCP (Chuq) (08/21/84)
Can anyone give good reasons for the existance of the article id locking
and unlocking routines in inews? I've looked through and I can't really see
any purpose to locking them and they seem to have a fair amount of overhead
involved. I believe some sites have removed them and not seen any problems
(apollo, was that you?) Can anyone out there remember why they were there
in the first place?
chuq
--
From the depths of the Crystal Cavern: Chuq Von Rospach
{amd,decwrl,fortune,hplabs,ihnp4}!nsc!chuqui nsc!chuqui@decwrl.ARPA
Dreams, dreams, enchanter! Gone with the harp's echo when the strings fall
mute; with the flame's shadow when the fire dies. Be still, and listen.glc@akgua.UUCP (G.L. Cleveland [Lindsay]) (09/14/84)
Chuq asked: >Can anyone give good reasons for the existance of the article id locking >and unlocking routines in inews? I've looked through and I can't really see >any purpose to locking them and they seem to have a fair amount of overhead >involved. I believe some sites have removed them and not seen any problems >(apollo, was that you?) Can anyone out there remember why they were there >in the first place? I find that under some systems/circumstances, two or more "rnews" processes may crank up to process the same input data (or the same article coming from two news feeds). If there were no locking of the article, it could be posted twice. If you can guarantee that only one "rnews" will ever run at one time on your system, then the locking code is not needed. Similarly, if you use the data-base code to maintain your history files and if it has "single-threading" of all requests, then you get the same effect as the locking code. Hope this helps. Cheers, Lindsay Lindsay Cleveland (...{ihnp4|mcnc|sdcsvax|clyde}!akgua!glc) AT&T Technologies/Bell Laboratories ... Atlanta, Ga (404) 447-3909 ... Cornet 583-3909