Re: TPC-A and -B Benchmarks

In article <1993Jul9.115312.8851@pyra.co.uk> graeme@uk.pyramid.com (Graeme Sargent) writes: > >One of the more difficult requirements to implement (without table >locking) is that new rows may not be inserted into the set defined by >your cursor during your transaction. > >I have yet to see an implementation of Repeatable Read that did not use >locking (and undesirably restrictive locking), but if Sandor can invent >one, I'm sure the world will be grateful. > I did this without the "physical" kind of locks I think your are refering to in a system I developed for fun once. It utilized "predicate locks". Before a row is inserted or modified, it is compared against all outstanding "where clauses" for all other open transactions. If the new/updated row satisfied an existing "where clause" it was disallowed. Needless to say, the way users' compose where clauses significantly influenced concurrency. Thought exercise: What type of access characteristics would an application need to have for this to be a useful technique? Scott