bote@csense.UUCP (John Boteler) (07/27/89)
In order for my brain to learn most effectively, it needs an
analogy:
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.
I am trying to envision 10 stock traders all scrambling
simultaneously to write the latest price of an issue on a
blackboard in a busy Manhattan center...how many can actually
have the right price? The latest price?
A man with two watches is never sure what time it is.
Someone please straighten me out.
--
Bote
uunet!cyclops!csense!bote
{mimsy,sundc}!{prometheus,hqda-ai}!media!cyclops!csense!botejkrueger@daitc.daitc.mil (Jonathan Krueger) (07/28/89)
In article <322@csense.UUCP>, bote@csense (John Boteler) writes: >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. There are several concurrency problems. They may be described in three broad groups: the lost update problem, the uncommitted dependency problem, and the inconsistent analysis problem (following Date, An Introduction to Database Systems, Volume I, Fourth Edition, Addison-Wesley, 1986). >I am trying to envision 10 stock traders all scrambling >simultaneously to write the latest price of an issue on a >blackboard in a busy Manhattan center...how many can actually >have the right price? The latest price? The market isn't a good source for examples. It's too complex. And as you point out, the real world supplies natural serializing mechanisms. But I'll try. Consider a table like: +-------+ | stock | owner shares company +-------+--------+--------+----------+ | Smith | 5000 | Sony | | Jones | 5000 | Sony | | Trump | 40000 | Sony | +--------+--------+----------+ We run a report to tell us where the sharks are: owner company ownership ----- ------- --------- Trump Sony 80% Now Sony issues 50,000 more shares and Trump buys them: +-------+ | stock | owner shares company +-------+--------+--------+----------+ | Smith | 5000 | Sony | | Jones | 5000 | Sony | | Trump | 90000 | Sony | +--------+--------+----------+ Now, what will the report say? Well, there are two correct answers, either 90% or 80%. The first is correct if the row has been updated before the report is run, the second if the opposite is true. There are also two incorrect answers: 40% or 180%. The first happens if we fetch Trump's ownership before the update occurs and compute the aggregate after, the second if the opposite is true. Both incorrect answers are examples of the inconsistent analysis problem. They can be prevented by various methods of concurrency control. A common method is locking. If the report is in progress when the update is submitted, the update is locked out until the report is completed. If the update is in progress when the report is started, the report is locked out until the update is committed or rolled back. Does this help? -- Jon -- --
jbeard@quintus.UUCP (Jeff Beard) (07/28/89)
As an example of 'real life concurrency', Let a family of four have a girl and a boy, both teenagers with divers licenses. Due to a mechanical problem on the second car, mom's VM is in the shop. Dad has a buisness meeting across town at 8pm, junior wants to go to the drive-in with his date, and sis is scheduled to be at her job at 8pm ... of course it is at the other end of town. Concurrency control is necessary and is in fact defacto ... there is only one car. He who grabs the keys gets to run away, all the others get to stay!
larry@macom1.UUCP (Larry Taborek) (08/02/89)
From article <322@csense.UUCP>, by bote@csense.UUCP (John Boteler): > In order for my brain to learn most effectively, it needs an > analogy: > > 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. "Its my turn." Sibbling A "No its mine." Sibbling B "Its mine." Sibbling A "Mine" Sibbling B Adults emulate concurrency through ques (waiting in line at a bank, imagine everyone trying to do their transaction at the same time at a common teller), and through round robin scheduling ("Next please!"). People in the real world don't deal with concurrency like a computer because its so obvious. If your at a rental company and all their (cars,rv's,boats,whatever) are gone and the lots empty, then off you go to another rental company or give up. Hope this helps... Larry -- Larry Taborek ..!uunet!grebyn!macom1!larry Centel Federal Systems larry@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 703-758-7000
bote@csense.UUCP (John Boteler) (08/10/89)
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
john@anasaz.UUCP (John Moore) (08/12/89)
In article <328@csense.UUCP> bote@csense.UUCP (John Boteler) writes:
]
]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.
Try this one from our current project. We are implementing a
hotel reservation system. We have tuples representing the
number of rooms not sold on a particular date for a particular
room type for a hotel. It is not at all uncommon for more than
one user to attempt to book the same room type at the same
hotel on the same day. Thus, concurrency control is needed.
--
John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john
(602) 861-7607 (day or eve) long palladium, short petroleum
7525 Clearwater Pkwy, Scottsdale, AZ 85253
The 2nd amendment is about military weapons, NOT JUST hunting weapons!bengsig@oracle.nl (Bjorn Engsig) (08/16/89)
Another example of real life concurrency is this, which I have experienced my self: You go to one of the checkin counters in an airport, specify what kind of seat you want, and is told that e.g. 13B is available. A few seconds later (when the 'COMMIT' key is pressed) 13B is gone! Apparantly, this systems follows the 'reread-before-write' rule and not the 'lock-on-read' rule. The latter would without doubt give too many seats locked for too long time and decrease the overall throughput, whereas the former does give the kind of trouble I've described. -- Bjorn Engsig, ORACLE Europe \ / "Hofstadter's Law: It always takes Path: mcvax!orcenl!bengsig X longer than you expect, even if you Domain: bengsig@oracle.nl / \ take into account Hofstadter's Law"