From: | Quartz <quartz12h(at)yahoo(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: JDBC gripe list (the autocommit subthread) |
Date: | 2011-04-06 16:11:19 |
Message-ID: | 677089.43685.qm@web33202.mail.mud.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Once again...
You cannot assume a batch is a transaction. Especially, it may deadlock when application are batching statements expecting that affected rows won't be locked in groups.
--- On Fri, 4/1/11, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> From: Dave Cramer <pg(at)fastcrypt(dot)com>
> Subject: Re: [JDBC] JDBC gripe list (the autocommit subthread)
> To: "Quartz" <quartz12h(at)yahoo(dot)com>
> Cc: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-jdbc(at)postgresql(dot)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(at)yahoo(dot)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(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-jdbc
> >
>
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2011-04-06 21:35:08 | Re: JDBC gripe list (the autocommit subthread) |
Previous Message | Quartz | 2011-04-06 16:07:28 | Re: JDBC gripe list (the autocommit subthread) |