From: | Quartz <quartz12h(at)yahoo(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: JDBC gripe list |
Date: | 2011-03-29 20:34:31 |
Message-ID: | 483657.70223.qm@web33207.mail.mud.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Keep reading:
http://download.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29
"If one of the commands in a batch update fails to execute properly, this method throws a BatchUpdateException, and 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. If the driver continues processing after a failure, the array returned by the method BatchUpdateException.getUpdateCounts will contain as many elements as there are commands in the batch, and at least one of the elements will be the following[...]"
"The possible implementations and return values have been modified in the Java 2 SDK, Standard Edition, version 1.3 to accommodate the option of continuing to proccess commands in a batch update after a BatchUpdateException obejct has been thrown. "
For those who believe the driver is fine when breaking the batch after the 1st error, then in my example of 5 inserts with pk id=1 to 5 (with id 2 and 4 already present) the table won't contain at least the id=1 (which didn't fail).
The postgres driver is partly at fault, but the server is too, for making a transaction whene there is none. Try to get any of the 2 sides to work on it and they just throw the problem the other way:
"[server guys]: oh its a driver issue then!..."
"[driver guys]: oh, its a server issue then!..."
Nothing gets done, and we are stuck.
--- On Tue, 3/29/11, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> From: Dave Cramer <pg(at)fastcrypt(dot)com>
> Subject: Re: [JDBC] JDBC gripe list
> To: "Quartz" <quartz12h(at)yahoo(dot)com>
> Cc: pgsql-jdbc(at)postgresql(dot)org
> Received: Tuesday, March 29, 2011, 4:17 PM
> On Tue, Mar 29, 2011 at 3:29 PM,
> Quartz <quartz12h(at)yahoo(dot)com>
> wrote:
> > addBatch()/executeBatch() is broken under
> autocommit=true.
> >
> > Every statement is clearly supposed to be
> independant.
> > Example: 5 insert statements, let's say the 2th and
> the 4th are on duplicate of primary key. All 3 others should
> still be performed but they aren't.
> >
> > This breaks our application. We migrated from mysql,
> and BOOM...
> >
>
> I would think the concept of execute batch would infer that
> they
> should all commit or none should. This line from the API
> seems to
> infer that
>
> "Submits a batch of commands to the database for execution
> and if all
> commands execute successfully, returns an array of update
> counts."
>
> Where it states "if all commands execute successfully"
> implies a
> transaction in the postgresql world.
>
> Dave
>
> >
> > --
> > 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 | Kevin Grittner | 2011-03-29 20:49:14 | Re: JDBC gripe list |
Previous Message | Dave Cramer | 2011-03-29 20:17:29 | Re: JDBC gripe list |