Wanted - opinions, advice on benchmarking contention

From: Mike Winters <mwinters_at_axon.nlm.nih.gov>
Date: 1995/05/10
Message-ID: <1995May10.221213.10277_at_nlm.nih.gov>#1/1


We are considering Oracle for some particular tasks, but have to test it for some of the following:

  1. Test for contention detection/resolution when multiple updates are occurring simultaneously.
  2. Test for #1 by determining how Oracle handles "dirty reads".

One way to test #1 and #2 is by setting up a loop in a C program with calls to the Oracle DBMS kernel. This way, one user can try accessing a row(s) while another user is continuously updating the table. Granted, in real life, this may not happen very often, but I would think that you would have to make a "contrived" situation, such as updating a table over and over again in a loop, to FORCE it to happen, so you can see how Oracle (or any other DBMS package) handles the issue of contention/detection resolution.

As part of these tests, I am trying to determine the best way a DBMS should handle contention. In my opinion, a user performing a dirty read should get a snapshot of the last update of the record BEFORE it was updated - Oracle or any other DBMS should not lock up or bomb out with an error message. For handling multiple updates, this is a trickier issue. I suppose you could let whoever gets to the record first to put a default lock on the record.... Any advice or opinions on this aspect of Oracle would be highly appreciated. ------ Mike

who ever accesses the record first to put a lock on the record....

Any opinions or advice on ways to adequately test this important issue with Oracle (i.e. writing a particular kind of Pro*C program) Received on Wed May 10 1995 - 00:00:00 CEST

Original text of this message