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
>
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 |
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 |
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 |