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:

Previous
From: Quartz
Date:
Subject: Re: JDBC gripe list (the autocommit subthread)
Next
From: Oliver Jowett
Date:
Subject: Re: JDBC gripe list (the autocommit subthread)