Re: JDBC gripe list (the autocommit subthread) - Mailing list pgsql-jdbc

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