Re: JDBC gripe list - Mailing list pgsql-jdbc

From Quartz
Subject Re: JDBC gripe list
Date
Msg-id 121151.6377.qm@web33207.mail.mud.yahoo.com
Whole thread Raw
In response to Re: JDBC gripe list  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List 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 by date:

Previous
From: Quartz
Date:
Subject: Re: JDBC gripe list (the autocommit subthread)
Next
From: "Kevin Grittner"
Date:
Subject: Re: JDBC gripe list (the autocommit subthread)