Re: JDBC gripe list

Поиск
Список
Период
Сортировка
От Quartz
Тема Re: JDBC gripe list
Дата
Msg-id 121151.6377.qm@web33207.mail.mud.yahoo.com
обсуждение исходный текст
Ответ на Re: JDBC gripe list  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-jdbc
> > 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
justintended 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
preventthe 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
makea better driver. 


В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Quartz
Дата:
Сообщение: Re: JDBC gripe list (the autocommit subthread)
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: JDBC gripe list (the autocommit subthread)