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 по дате отправления: