Re: TPC-A and -B Benchmarks

>Date: Thu, 8 Jul 93 14:55:30 +0200 >From: "Sandor (Mr. Oracle7)" <uunet!nl.oracle.com!SNIEUWEN> >To: informix-list@rmy.emory.edu >Subject: Re: TPC-A and -B Benchmarks >X-Informix-List-Id: <list.2476> >What strikes me the most is that all messages about the subject of >repeatable reads, read consistency, cursor stability, isolation levels >etc, all discuss 'how a database should implement a certain feature' >instead 'whats the purpose of a feature'. Good point. >I don't see why you should use locks to implement repeatable reads. >Locking is just one way (and I don't think it is the best way). >Multiversioning, like Oracle implements is another way, which will not >cause any locks. The main reason why you use something like this is to >retrieve the correct data, not because you'd want to lock data. Correct. >Superfluous locking of data (even row locks) will cause serious >performance degradation. Isn't the danger that you trade forced rollbacks for locks? Suppose we are using a multi-versioning system and wish to maintain a repeatable read isolation level on a transaction TX1 doing updates. TX1 reads Table1/Row1/Version1 (T1/R1/V1 for brevity). At some time later, some other transaction TX2 reads, updates and commits T1/R1/V1, producing T1/R1/V2. So far, so good. Now TX1 re-reads T1/R1 and receives the T1/R1/V1 -- great; TX1 has got repeatable read. But if TX1 now updates T1/R1/V1, what happens? Given that TX2 has made a committed change to the data, TX1 cannot be allowed to adjust T1/R1/V1 because it needs to know what was done to produce T1/R1/V2 -- it might change what TX1 should do. So TX1 has to be returned an error along the lines of "cannot update row -- stale data". If the purpose of TX1 is to update T1/R1, it will have to be rolled back, because no amount of waiting will make the data any less stale. My memory of the correct name for this form of concurrency control is hazy, but I think it is one of Wound/Wait and Wait/Die -- I'd opt for Wait/Die if forced to choose (and if I've got it all wrong, I apologise). The other form of concurrency control would prevent TX2 from doing its update. Either way, the penalty for not having locking is that if two independent transactions try to update the same row, one of them has to be rolled back. If you want a reference on this, try "Concurrency Control and Recovery in Database Systems" by P.A.Bernstein, V.Hadzilacos, N.Goodman. It's more than a year since I last looked at this, so I should be having another read myself. Yours, Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h> -- These opinions are just mine and not those of Informix Software ---