Re: JDBC behaviour

From: Sridhar N Bamandlapally <sridhar(dot)bn1(at)gmail(dot)com>
To: Andreas Joseph Krogh <andreas(at)visena(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC behaviour
Date: 2016-02-18 09:20:51
Message-ID: CAGuFTBXf_1Vws=Ja3nCqvRGvWPE2W4ATpCyxrreCgWFi0Yii=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-jdbc

setAutoCommit(false), it should not be treating all next transactions as
single set, simple, this is what expected behavior

On Thu, Feb 18, 2016 at 2:34 PM, Andreas Joseph Krogh <andreas(at)visena(dot)com>
wrote:

> På torsdag 18. februar 2016 kl. 09:51:47, skrev Sridhar N Bamandlapally <
> sridhar(dot)bn1(at)gmail(dot)com>:
>
> Ok, let me put this way
>
> in JDBC we have *setAutoCommit( false ) *, and all dmls are independent
> transactions
>
> and when any transaction fails then the session not allowing next
> transactions
>
> in Java when we do setAutoCommit( false ) its behaving like all
> transactions in BEGIN-END block, this is not expected behavior
>
> i guess this is bug
>
>
> No, you got it backwards. With autocommit=false all statements are NOT
> independent transactions.
>
> --
> *Andreas Joseph Krogh*
> CTO / Partner - Visena AS
> Mobile: +47 909 56 963
> andreas(at)visena(dot)com
> www.visena.com
> <https://www.visena.com>
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Oleg Bartunov 2016-02-18 09:21:04 Re: Query plan not updated after dropped index
Previous Message Andreas Joseph Krogh 2016-02-18 09:04:56 Re: JDBC behaviour

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladimir Sitnikov 2016-02-18 09:24:07 Re: JDBC behaviour
Previous Message David Rowley 2016-02-18 09:19:08 Re: Performance improvement for joins where outer side is unique

Browse pgsql-jdbc by date

  From Date Subject
Next Message Vladimir Sitnikov 2016-02-18 09:24:07 Re: JDBC behaviour
Previous Message Andreas Joseph Krogh 2016-02-18 09:04:56 Re: JDBC behaviour