Re: JDBC gripe list (the autocommit subthread)

On Wed, Mar 30, 2011 at 10:55 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Quartz <quartz12h@yahoo.com> wrote:
>
>> If addBatch was not meant to be called when autocommit=true, then
>> it would have thrown an exception. The point is to enable multiple
>> statement in 1 executeBatch call. Just imagine a system that
>> separates who makes statements and who executes them. Like event
>> logging lets say. Meanwhile, there are infinite cases where
>> multiple statements are not (and must not) be in a all-or-nothing
>> transaction. This is why applications choose to set
>> autocommit=true to obtain the batch behavior without a TX. It's in
>> the API for such reasons.
>
> The docs say something completely at odds with your assertion:
>
> | a JDBC driver may or may not continue to process the remaining
> | commands in the batch. However, the driver's behavior must be
> | consistent with a particular DBMS, either always continuing to
> | process commands or never continuing to process commands.
>
>> It is just incorrect to consider the batch is 1 transaction when
>> the API clearly exposes the ability to avoid it.
>
> And the option not to.
>
>> As I wrote earlier, calling applications that just pile up updates
>> in a batch not expecting any deadlock due to row locking by each
>> statement, will not work anymore.
>
> Anymore?  When did batches in PostgreSQL work that way?
>
>> The fact the API have autocommit independant from batches means it
>> serve a purpose. I see it. But even if I didn't, the API says so
>> and I can't second guess it.
>
> You are misreading it.
>
>> I know it hurts to learn such truth after such a long delay.
>> You'll get over it!
>
> That's not the way to persuade people.  You're approaching the point
> where people will just start ignoring your posts as noise.
>
> The bottom line is that there is a perfectly clean and portable way
> to run the statements such that you can ignore or retry failures --
> execute each separately in your Java code.  That you chose to use an
> API which allows but doesn't require a driver to support the
> behavior you want doesn't make the behavior mandatory.  Most people
> use the batch feature for performance, and in PostgreSQL it would
> reduce the performance of the batch feature to accommodate what you
> propose.
>
>> I have found a 4 year old bug lately, in my own code. I know the
>> feeling.
>
> It would appear that you've found but not yet recognized another bug
> -- inappropriate use of an API.  You're counting on an
> implementation detail rather than the documented API, and that's a
> bug.
>
> -Kevin
>

Thanks Kevin

+1

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca