Re: JDBC gripe list

> > it would be done in a transaction otherwise what is
> the point ?
>
> That's a fair question.  A batch will almost always
> run faster if
> done as a single transaction which either runs in its
> entirety or
> fails in its entirety.  What is the reason for wanting
> to use batch
> processing if not for speed?  I think we need to see a
> reasonable
> use case from someone advocating this change in order to
> justify it.
> (Note: "It works in MySQL" won't cut it.)
>
> -Kevin
>

I wrote earlier that the batch is independant form the will to make it a transaction for a few reasons:

a) you can't control the row locks involved in the batch, and you could end up in a deadlock. This is frequent when you just intended to pile up statements for another thread to call executebatch.

b) you just want to run a playlist of independant SQLs not related to each other and you don't expect some failures to prevent the others from running.

The batch works independantly from a transaction. I can't stress this differently. Maybe you have never used it this way, or learned it with a biased perspective that batches is only for transaction. I hope I gave a fresh perspective to make a better driver.