Re: JDBC gripe list (the autocommit subthread) - Mailing list pgsql-jdbc
From | Quartz |
---|---|
Subject | Re: JDBC gripe list (the autocommit subthread) |
Date | |
Msg-id | 677089.43685.qm@web33202.mail.mud.yahoo.com Whole thread Raw |
In response to | Re: JDBC gripe list (the autocommit subthread) (Dave Cramer <pg@fastcrypt.com>) |
Responses |
Re: JDBC gripe list (the autocommit subthread)
|
List | pgsql-jdbc |
Once again... You cannot assume a batch is a transaction. Especially, it may deadlock when application are batching statements expectingthat affected rows won't be locked in groups. --- On Fri, 4/1/11, Dave Cramer <pg@fastcrypt.com> wrote: > From: Dave Cramer <pg@fastcrypt.com> > Subject: Re: [JDBC] JDBC gripe list (the autocommit subthread) > To: "Quartz" <quartz12h@yahoo.com> > Cc: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>, pgsql-jdbc@postgresql.org > Received: Friday, April 1, 2011, 5:49 AM > So what is the use case for > autocommit = true for batch inserts ? > > to me the whole point of batch inserts is speed with > autocommit= false > it should be faster. I would also think the logic is much > simpler if I > get an all or nothing commit. > > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > > On Thu, Mar 31, 2011 at 5:34 PM, Quartz <quartz12h@yahoo.com> > wrote: > >> I'm coming around to the position that we > shouldn't tinker > >> with > >> autoCommit within the executeBatch method. I > still > >> think it would > >> be best for us to consistently bail out on the > first > >> failure, but if > >> autoCommit is on, we could build the > BatchUpdateException > >> using an > >> array of the length of the successfully completed > >> statements. If > >> autoCommit is off, I'm not sure whether it would > be better > >> to leave > >> the updateCounts property null or use a zero > length array; > >> but > >> clearly no statements should be considered > successful. > >> > >> The API documentation does seem to suggest it > should work > >> that way. > >> > >> The bad news is that this would be a behavior > change, and > >> could thus > >> break existing code for current PostgreSQL users. > >> When that's the > >> case, we generally like to see a reasonable use > case for > >> the new > >> behavior even when it is standard. So far we > have a > >> rather > >> hand-wavy assertion that it would be useful for > logging and > >> "an > >> infinite number of" other uses. It would > probably > >> help sway the > >> community if there was a more concrete explanation > of why > >> this was > >> better than the alternatives for logging purposes, > and to > >> sketch out > >> one or two of the other infinite number of use > cases. > > > > > > You have been defending all that long that most use > the autocommit=false when using batches. Then they won't > break....! > > > > Besides that's what release notes are for. And I dare > say, if they expected a transaction when using a batch with > autocommit=true, it about time they learn their mistake. > JDBC api is a contract. Can't make exception for postgres. > > > > > > -- > > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-jdbc > > >
pgsql-jdbc by date: