Path: utzoo!attcan!uunet!cyclops!csense!bote
From: bote@csense.UUCP (John Boteler)
Newsgroups: comp.databases
Subject: Re: Concurrency control in real life
Message-ID: <328@csense.UUCP>
Date: 10 Aug 89 05:39:28 GMT
References: <4875@macom1.UUCP>
Organization: Common Sense Computing, McLean Va
Lines: 38

From article <4875@macom1.UUCP>, by larry@macom1.UUCP (Larry Taborek):
> From article <322@csense.UUCP>, by bote@csense.UUCP (John Boteler):
>> I request that someone post a solid example of an instance
>> where concurrency is a problem to control, perhaps with
>> a discussion of concurrency issues relating to the example.
> Humm, thats a good one.
> How about sibblings fighting over a toy.

Boy, I had no idea how wide open a response I would receive...

I appreciate all the responses I have received, they all made
me think, which is nice.

I was particularly asking for a real-life (computer?) solution to
a problem which is not overly difficult to grasp; some of
those responding to me provided answers near this goal and
raised new questions for me. 

As I review my strategy for maintaining data integrity, I actually
asked myself how often or how useful the methods I employ in
applications are really proven useful: would there realistically
ever be an occasion when two or more people would be adding
or modifying a tuple simultaneously? 

This is not as simple a question as it appears on its face...are 
there useful optimizations to be made without loss of generality?

At present, I create temporary files for posting new data
using the current time as part of the file name, then append
to the master database. Last file to append to the master table
gets the worm. What considerations have I missed?  Any?  Other scenarios?

It might be worth shaking the cobwebs out for few rounds here...

-- 
Bote
New & Improved path!: uunet!comsea!csense!bote
{mimsy,sundc}!{prometheus,hqda-ai}!media!cyclops!csense!bote