Re: JDBC behaviour

From: Sridhar N Bamandlapally <sridhar(dot)bn1(at)gmail(dot)com>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC behaviour
Date: 2016-02-18 10:43:36
Message-ID: CAGuFTBWODgA_-JLGWBHqg_2NUZWDiKZSUkNgFJj_CZ4gZcqjVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-jdbc

The code/framework is written to handle batch inserts, which is common for
all databases

I feel, PostgreSQL JDBC may need to modify setAutoCommit(false) code to
"implicit savepoint - on error - rollback to savepoint"

On Thu, Feb 18, 2016 at 3:59 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:

>
>
> if you want each insert to work indepedently yet stay with the transaction
> model, then each insert should be its own transaction...
>
>
> conn.setAutoCommit(false);
> executeUpdate("insert into employee(id,name) values(1, 'K1')");
> conn.commit();
> executeUpdate("insert into employee(id,name) values(1, 'K1')");
> conn.commit();
> executeUpdate("insert into employee(id,name) values(1, 'K2')");
> conn.commit();
>
> otherwise the way you wrote it, its a single transaction. all three
> inserts have to succeed, otherwise, all three are rolledback. why is
> that so hard to understand?
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> 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
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dave Cramer 2016-02-18 10:52:03 Re: JDBC behaviour
Previous Message Victor Blomqvist 2016-02-18 10:32:49 Re: Query plan not updated after dropped index

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2016-02-18 10:52:03 Re: JDBC behaviour
Previous Message Andres Freund 2016-02-18 10:37:51 Re: checkpointer continuous flushing - V16

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2016-02-18 10:52:03 Re: JDBC behaviour
Previous Message John R Pierce 2016-02-18 10:29:37 Re: JDBC behaviour