Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site akgua.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!mcnc!akgua!glc
From: glc@akgua.UUCP (G.L. Cleveland [Lindsay])
Newsgroups: net.news.b
Subject: Re: idlock() in inews?
Message-ID: <984@akgua.UUCP>
Date: Fri, 14-Sep-84 00:17:42 EDT
Article-I.D.: akgua.984
Posted: Fri Sep 14 00:17:42 1984
Date-Received: Tue, 25-Sep-84 03:08:40 EDT
References: <1338@nsc.UUCP>
Organization: AT&T Technologies/Bell Labs, Atlanta
Lines: 28

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