Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

294
CHAPTER 9 ■ REDO AND UNDO
rowcnt++;
if ( rowcnt == commitCount )
{
con.commit();
rowcnt = 0;
committed++;
}
}
con.commit();
long end = new Date().getTime();
System.out.println
("pstatement " + count + " times in " +
(end - start) + " milli seconds committed = "+committed);
}
}
Now we’ll run this code repeatedly with different inputs:
$ java perftest 10000 1
pstatement 1 times in 4 milli seconds committed = 1
pstatement 10000 times in 11510 milli seconds committed = 10000
pstatement 10000 times in 2708 milli seconds committed = 1
$ java perftest 10000 10
pstatement 1 times in 4 milli seconds committed = 1
pstatement 10000 times in 3876 milli seconds committed = 1000
pstatement 10000 times in 2703 milli seconds committed = 1
$ java perftest 10000 100
pstatement 1 times in 4 milli seconds committed = 1
pstatement 10000 times in 3105 milli seconds committed = 100
pstatement 10000 times in 2694 milli seconds committed = 1
As you can see, the more often you commit, the longer it takes (your mileage will vary on
this). This is just a single-user scenario—with multiple users doing the same work, all committing
too frequently, the numbers will go up rapidly.
We’ve heard the same story, time and time again, with other similar situations. For example,
we’ve seen how not using bind variables and performing hard parses frequently severely
reduces concurrency due to library cache contention and excessive CPU utilization. Even
when we switch to using bind variables, soft parsing too frequently, caused by closing cursors
even though we are going to reuse them shortly, incurs massive overhead. We must perform
operations only when we need to—a COMMIT is just another such operation. It is best to size our
transactions based on business need, not based on misguided attempts to lessen resource
usage on the database.
There are two contributing factors to the expense of the COMMIT in this example: