Re: JDBC gripe list
| От | Quartz |
|---|---|
| Тема | Re: JDBC gripe list |
| Дата | |
| Msg-id | 483657.70223.qm@web33207.mail.mud.yahoo.com обсуждение исходный текст |
| Ответ на | JDBC gripe list (Dave Cramer <pg@fastcrypt.com>) |
| Ответы |
Re: JDBC gripe list
("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: JDBC gripe list (Dave Cramer <pg@fastcrypt.com>) Re: JDBC gripe list (Oliver Jowett <oliver@opencloud.com>) |
| Список | 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@fastcrypt.com> wrote: > From: Dave Cramer <pg@fastcrypt.com> > Subject: Re: [JDBC] JDBC gripe list > To: "Quartz" <quartz12h@yahoo.com> > Cc: pgsql-jdbc@postgresql.org > Received: Tuesday, March 29, 2011, 4:17 PM > On Tue, Mar 29, 2011 at 3:29 PM, > Quartz <quartz12h@yahoo.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@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-jdbc > > > |
В списке pgsql-jdbc по дате отправления: