Re: JDBC behaviour

There are many reasons why this is required,

1. Postgres migrated client percentage is high,

2. For application developers this looks like bug in Postgres, as it throw
exception for next transaction even when current exception
suppressed/handled,

3. Most of non-financial application or data-ware-house application have
batch transaction process where successful transaction goes into
data-tables and failed transactions goes into error-log-tables,

this is most generic requirement

cannot effort any reason if client think about rollback to old database or
feel not meeting requirements -- please ignore

On Thu, Feb 18, 2016 at 7:06 PM, Mark Rotteveel <mark(at)lawinegevaar(dot)nl>
wrote:

> On Thu, 18 Feb 2016 13:48:04 +0100 (CET), Andreas Joseph Krogh
> <andreas(at)visena(dot)com> wrote:
> > I understand that and indeed this isn't something that should be
> handled
> > by the driver, however some of the response in this thread seem to
> think
> > it
> > is an absurd expectation from the OP that failure of one statement
> should
> > still allow a commit. Which it isn't if you look at what other database
> > systems do.
> >
> > Mark
> >
> > If that one failed statement doesn't raise an exception, how does the
> > client
> > (code) know that it failed? If it does raise an exception, then what
> > standard
> > specifies that that specific exceptions is to be treated as "don't
> > rollback for
> > this type of error"?
>
> Of course an exception is raised, but the exact handling could then be
> left to the client. For example the client could catch the exception,
> decide based on the specific error to execute another statement to "fix"
> the error condition and then commit. Think of INSERT, duplicate key, then
> UPDATE before the existence of 'UPSERT'-like statements; if the occurrence
> of duplicate key is rare it can be cheaper to do than to first SELECT to
> check for existence and then INSERT or UPDATE, or to UPDATE, INSERT when
> update count = 0. Another situation could be where the failure is not
> important (eg it was only a log entry that is considered supporting, not
> required), so the exception is ignored and the transaction as a whole is
> committed.
>
> Sure, in most cases it is abusing exceptions for flow control and likely
> an example of bad design, but the point is that it is not outlandish to
> allow execution of other statements and eventually a commit of a
> transaction even if one or more statements failed in that transaction; as
> demonstrated by systems that do allow this (for SQL Server you need to set
> XACT_ABORT mode on to get similar behavior as PostgreSQL).
>
> As to standards, for batch execution, JDBC expects that a driver either
> process up to the first failure and raise a BatchUpdateException with the
> update counts of the successfully executed statements, or continue
> processing after failure(s) and only raise the exception after processing
> the remainder of the batch (where the exception contains a mix of update
> counts + failure indications). In both cases a commit for the statements
> that were processed successfully would still be possible if the client so
> wishes (see section 14.1.3 "Handling Failures during Execution" of JDBC
> 4.2).
>
> Mark
>
>
> --
> 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
>