oracle jdbc bug?

this applies to java 1.1.8 (and oracle's jre and driver set under 8.1.5) if this problem is fixed under 1.2 and 8.1.6 please advise.

for performance reasons i am using oracle's batch update methods.
(OraclePreparedStatement)setExecuteBatch(int numberofrows)

there appears to be a bug in the way oracle handles the batch on a commit statement.

for example:

insert_ps = conn.prepareStatement

       ("insert into table (attr) values (?)");
(OraclePreparedStatement)insert_ps.setExecuteBatch(500);

// first insert loop
for (int i=0; i<750; i++) {

      insert_ps.setLong(1, i);
      insert_ps.executeUpdate();

// second insert loop
for (int j=0; j<750; i++) {

    insert_ps.setLong(1,j);
    insert_ps.executeUpdate();
}
comm.commit();

the above code works great. in the first insert loop, on the 500th iteration, executeUpdate batch inserts all the rows like it is supposed to. the loop continues until iteration 750 whereby there are 250 rows batched. the commit following the loop, first inserts these 250, and then commits the entire 750. the second loop works in exactly the same way.

the problem arises when the first loop inserts less than the 500 rows. if instead of:
for (int i=0; i<750; i++) {
we used
for (int i=0; i<300; i++) {

the loop would not insert the batched rows, until the commit statement following. only the accumulated 300 would be batched and committed. when this happens, the second loop causes my JRE to crash (no exceptions, just a nasty program halt). it crashes on the 500th insert, when executeUpdate inserts the previously batched 500 rows. my guess here is that although the batch_count is 500, because only 300 rows were inserted in the first loop, the buffer for the insert rows is only sized for 300 as opposed to the full 500 in the first successful trial.

has anybody else encountered this bug. if so, are you aware of any patches or good work arounds?

thanks,

tonys. Received on Sun Jul 30 2000 - 00:00:00 CEST